Project Management Software
Specialists in Project Infrastructure
It is often hard to understand why IT projects can be so difficult. People in the Engineering/Construction project management area are shocked at how over time, and over budget IT projects can become. Perhaps it is time to compare a construction project and an IT project to understand why they are different.
For our example, let us choose two projects. The construction project is to build a new house. The IT project is to build a customer management system to replace a manual record keeping function.
Approach to a House Building Project
If we were to build ourselves a house, we would probably start with a number of things in place.
Approach to a Customer Information Project
A typical IT project starts with a different set of information:
The Initial Differences
So where are the differences? I suggest the following:
In a software development, there may be a Sponsor, a Steering Committee, a key Business User, other Users, an IT department, an Architect etc. They are all involved in the decision making process. It is unlikely they will all sit down for the duration of the project and make all the decisions as a team. More likely there will be scores of decisions made by one or two people.
It is inevitable that many of these decisions will have a degree of incompatibility. For example the decision to allow all users to update client credit details made by the Sales Manager may be incompatible with the decision about who can update certain information made by the Security Manager, and different again to the decision by the Accounts Manager that only Supervisors can change credit details. The point is that the complexity of decisions can easily lead to contradictory requirements.
I have actually seen a system built where at the screen end of the application, users could change credit details, but the database which had been configured to meet security requirements would not accept the changes. To make it worse, there was no warning that the changes had not been applied. Fortunately it came out in testing before the system went live.
In a house building project, there is typically one decision maker – the wife. Sorry guys but that’s real life. The Project Manager or Builder is responsible for implementing the decisions. There is less diversified decision making.
Progress is easier to see with a house. You can walk around and see where the pipes for the hot water are going rather than have to inspect code to see what edits are being built into order entry screens.
In summary in a house building project, there is more central decision making, more visibility of progress so that errors are identified earlier, and less coordination of different points of view.
How far to go
As the project progresses, on a building, it is much easier to see how much work is left. The outstanding work is highly visible. The rooms may need to be painted, landscaping done, and a fence finished. With software, it is difficult to see the work outstanding. Often completion of one area identifies unforeseen work in another area. We complete a screen only to find performance issues with the database.
With a house, it seems the further you go the more visible the outstanding work becomes. With software, the reverse is often true. The further you go the more obscure the remaining work becomes – up to a point at least.
Once again visibility is a major factor. You can see what is physically missing from a house. You cannot see physically what is missing from software. A screen may be there, but does it do everything you expect? Only testing will answer the question, and final testing cannot take place until the application is complete.
This is one of the key differences. It leads on from the previous topic. In a house, there is an electrical system, a water system, a sewage system, etc. Each is relatively standalone, and interfaces are clearly defined. The hot water system may connect to the electrical system if it is electric hot water, but the interface is a simple power point. The guttering interfaces with the storm water system through a simple downpipe.
Consider an IT system. The interfaces can be extremely complex. There is no such thing as a standard interface in many cases. Linking to a database may seem relatively simple in IT interface terms but it can still take many days to get it right, much less get it performing to expectations. When faced with interfaces to legacy systems, or just getting the links to your corporate email in place, there is rarely such a thing as plug and play.
On one project I heard about, several days were lost because a driver was upgraded by a supplier and the testing team were not aware of the new driver. They were using an old driver that did work before a service pack was applied to XP. It took several days to work out that the cause might not be the application but the service pack that had been rolled out to their operating system.
A home consists of a number of almost self contained components that have clearly defined ways of connecting together. An IT system consists of a number of integrated components that may or may not have a way to connect together. If they do have a way of integrating, there are likely to be a number of options in how it can happen, and various configurations within those options.
Ability to Visualise
If I am describing a house, I can see it in my mind, and know what it will be like. It is hard to do the same in an IT system. The level of complexity is many orders of magnitude more in IT. A decision to make a field mandatory may have implications far beyond the IT system. For example, the decision to make phone numbers mandatory in an order entry system may cause all sorts of problems to cash sale staff. The customer just wants to pay their money and take their goods. Why do you need a phone number? This is another real life experience I have seen.
Whilst a wrong decision in a house may result in insufficient storage space, or inability to get the piano up to the second floor, the implications are usually more visible. If you have a piano and you want to put it on the second floor, you will likely think about how you will get it up there before you build the staircase. If you run out of storage space, you can always buy a cupboard and have it as a free standing storage unit.
This ability to visualise is another reason IT projects are more prone to cost and time overruns.
I recently was a member of a committee to develop standard project management terminology. It was interesting to understand the background to the need for an Australian standard. The key driver was that in the construction industry, interpretation of contracts was dependant on common meanings for words and phrases. It was effectively a legally driven need to ensure consistency in contracts. If a dispute arose, it should be clear that certain words mean certain things to everyone.
Construction contracts tend to be very specific – hence the need for consistent terminology – and quite detailed. There is often tens or hundreds of millions tied up in contracts and they have to be well thought out and involve a common, shared understanding.
Contrast this with IT contracts. It is usually well into a project that a statement of work is developed and a contract signed (if at all). It is unusual for the initial stage of requirements gathering to be covered by a contract, and many organisations would laugh at the idea. How can you quote on a piece of work when you don’t know what you don’t know? IT starts with less of an understanding of what is required than does building and construction.
I did some work for a home builder many years ago and was amazed that from someone saying they wanted to purchase a particular style of house, within 2 weeks, they could develop a final costing. That included deciding options, modifications and additions to the standard plan, doing a site inspection to determine any environmental costs and producing a final plan.
As an aside, I was more amazed that they could get the purchasers into a room and in 4 hours determine all the furnishings, fittings and colours for the house. My partner would take around 4 years to do that.
Contrast that with an IT project. You cannot produce a bill of materials and labour estimate with any confidence in 2 weeks for a significant project. You will probably put a caveat on the estimate that it may be out by a factor of 100% or more. The IT components are not that easy to estimate.
If you want to take two extremes in terms of achieving goals, at one end you could have building a house. At the other extreme you might have finding a cure for the common cold. People would expect that, with a little initial investigation, you could estimate with a high level of accuracy the cost of a house. It is not in the realms of reality to estimate how much to cure the common cold. There might be an early breakthrough or it may go on for decades. Whilst IT is not at the research end of the spectrum, it is somewhere around the middle.
The biggest risk with IT is that it is treated like building a house. Hopefully this white paper has illustrated where the differences lie. With an IT project, complexity will become evident all through the project. If you want to fix the budget and time early in the project, and are not prepared to adjust it, you have two options:
Working harder will only take you so far. Working smarter can only improve productivity a certain amount. Sometimes the only solution to meet your objectives is to throw more money, resources and time at the project.
Finally, don’t treat an IT project like building a house. The approach required is different for all the reasons above. If you set expectations that we can cater for what we know today but we also need to cater for what we don’t know, you are more likely to deliver a satisfactory result.