Understanding if you are in an out-of-control IT project is important. Here are some traits of failing or soon-to-fail projects. If you have three or more of these project attributes, you need a project "reboot."

Dennis Brandl, BR&L Consulting

Share

As control engineers, we want to be well “in control.” Sometimes this is hard with a large software project. Software is difficult to view and understand during the development phase, and many projects can spin out of control without upper management even being aware of problems.

Projects can be unsuccessful for many reasons; the most common is a failure to “reboot” the project when it is heading down the wrong path. It’s hard to stop a project, even when most project members know that there are major problems and no planned solutions. For managers, it is known as the Gamble’s Dilemma: After spending $2 million on a project, it’s a difficult decision to stop it and restart, even if the final total cost will be less and actual time will be shorter. Understanding if you are in an out-of-control project is important.

-----------------------------------------------------------------------------

40 Under 40 – Control Engineering: Know someone working in automation under age 40 in need of some recognition? See the 40 Under 40 awards.

-----------------------------------------------------------------------------

Here are some habits common to uncontrolled projects that might help you identify if yours is one. Few failing or soon-to-fail projects will exhibit all of these traits. However, if your project has three of more, fix them before your project spins out of control. Or, consider “rebooting” the project with better controls.

1. No architect or architect team. Without a controlling influence to keep a design on track, small changes will accumulate, too often leading down dead ends or to bad decisions. If you don’t know where you are headed, then any direction seems like the right path.

2. No firm schedule. If no one knows the real schedule, or if the schedule seems to slip one week for every two calendar weeks, then the project is out of control and will never be completed on time, on budget, and with the required functionality.

3. Schedules are maintained in spreadsheets. Or, task lists are maintained in documents, and designs are in presentation files. This indicates an inability to use the right tools for the jobs—and there are many specialized project support tools that reduce the time and effort required to manage a project. Another indication of not using appropriate tools is multiple manual processes for installation, upgrades and patches; these could be automated through scripts and command files.

4. Project management has a “failure is not an option” mentality. While this is a good motto for a mission statement when your team is going to the moon, it leads to bizarre behavior in IT projects. If failure is to be punished, then people don’t report failures and management is often blissfully unaware of major problems. Similar unproductive project mottos are “right the first time” and “there are no problems, only opportunities.”

5. No configuration management or source control of documents or code. If a lot of time is lost in trying to locate needed information and confirming that it is the most current information, then better control is needed of deliverables. When team members’ best methods for sharing files and project information is through emails and USB drives, then robust configuration management processes are missing.

6. No documentation, test case, or code reviews. When a project is late and resources are stretched thin, reviews are one of the first tasks to be skipped. This is short-sighted behavior and will invariably lead to multiple problems later in the project, usually requiring extensive rework.

7. Design and test documents are not up-to-date. Until code is actually delivered the only information that is available for test development and integration design are the design documents.

If the project leadership plans on updating designs and tests after the coding is complete, then major integration and testing problems will inevitably occur.

Read more IT and Engineering Insight.

Also read: How to Avoid Project Failure.

Dennis Brandl is president of BR&L Consulting in Cary, NC, www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl(at)brlconsulting.com.