Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

The Waterfalls and Rapids of IT Projects: Can Project Managers Survive Them?

~ By Vernon Riley

Abstract word cloud for Rapid Application Development with related terms

Even when a good governance structure is in place the structure of an IT project is more important than is often assumed. The structure can make estimating difficult, and make it impossible to deliver whilst retaining the confidence of the management and external stakeholders. Yet the structure is often assumed without proper debate - either with the customer or with the project team.

Many organisations and project managers still like to use the so called "waterfall" method of controlling IT projects, because they believe it gives them greater commercial control, and allows fixed cost projects. This method splits up the total project into a series of logical steps:

  • Work out what items should be done
  • Estimate what these will cost
  • Agree these definitions and costs
  • Undertake formal design
  • Build the items
  • Test the items
  • Deploy and use the items

The waterfall method can appear to offer a clear logical path from inception through to completion. The commercial control supposedly occurs because the facts are determined before agreement is reached, thereby allowing the following steps to be controlled within an agreed financial framework.

If the project uses "well known" technology or is very similar to previous projects then the waterfall method can be successfully used. Where there is a substantial part that is new, or uncertain some serious issues exist with this approach.

In some cases the proportion of the total project costs and time that needs to be spent before sufficiently precise estimates are generated can be substantial. Clients and suppliers can disagree whether this should this be free or paid for. In many cases a messy compromise is arrived at where the costs of the business analysis and estimation will be paid for (or at least negotiated about) after it is decided whether the project is to be accepted.

In other cases it isn't certain that people are good at thinking through complex systems with sufficient accuracy to make the design "fit for purpose," prior to some good "proofs of concept."

Quite apart from the difficulty of identifying the "facts;" the fixing of features up front can lead to an 80/20 split where 80% of the costs produce 20% of the benefits and vice versa. This should give most clients cause for concern.

There can also be significant change in the business requirements during a project of 2 or 3 years duration. This has encouraged the move to Rapid Application Development (RAD).

Good Estimates Are Difficult

It is difficult to produce good estimates. Increasing the granularity can lead to estimating safety margins being accumulated (if say the minimum estimating unit is 1 day - then something that took 1 hour would be recorded as 1 day giving a 7 hour accumulation per task of this length).

Estimates need to be distinguished from use of historical data to give timings. But the latter need to be very carefully annotated and used to ensure they are being used properly.

Perhaps the thought that "estimation should be democratically controlled, and execution involve authoritarian methods rather than as often happens the other way around;" is one of the most useful maxims here.

Acceptance of the Facts

It is very difficult to know the extent to which the ultimate customer actually has bought into the design and estimates being produced. There may in fact be no acceptance other than of "that is the way our supplier chooses to do things" giving the opportunity for later disputes.

In some projects it can be very difficult to establish who is entitled to sign-off documents as correct on behalf of the organisation. This makes any approach other than time and materials problematic.

Rapid Application Development (RAD)

Rapid development techniques are now accepted in many cases. These methods involve using a number of iterative prototypes are built to give the customer greater control over the finished result. Thus the analysis, design, build and test sequences of the whole project is split into a number of successive cycles.

There are, however, unanswered questions about the range of IT projects for which RAD is suitable, and issues about whether all of the suggested elements of RAD are as important as one another. For instance some approaches time-box 3 to 6 week periods, whilst others simply allow incremental delivery over a number of months. Yet others regard the complete incorporation of automated unit testing into the coding (build) stage as perhaps the most important contribution.

There are numerous variations on RAD, including pairing - where two programmers work together with one writing tests and the other writing code to satisfy those tests. There is still a real need however to prioritise the efforts.

Some of the serious criticisms of RAD are that it can allow scope creep, lack of rigour, and cost overruns. It can be particularly difficult to stop "gold plating" on particular easily understood elements (e.g. the user interface) at the expense of underlying functions that are more complex and less easily explained or understood by business people, when the latter are involved in the assessment of each iteration.

Here again, we encounter evidence that the structure of the project can have substantial impact on the viability of the development.

There are a number of problems therefore with both traditional and RAD methods of controlling custom and or complex IT projects. Many projects would be improved if expert help and more time were spent restructuring the project at the start to help the IT supplier clarify the design choices and the IT client clarify the business requirements. Whilst this does involve an explicit acceptance that money will be spent "investigating" and "researching;" this is actually nothing more than bringing present good practice out into the open.


Vernon Riley is a senior consultant who understands both project management and technology. He has 20 years experience of major IT projects, and the difficulties of delivering complex projects.


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
1500
Enter the last letter of the word satellite.
Notify me of new comments via email.
Remember my form inputs on this computer.

Extreme Project Management

The running back dives for the first down with the defender on his back

Three war room strategies to try when you need to bring life back to a dead project, or save an engagement that is on the brink of disaster.

The 8-Step Guide to Creating a Quality Project Schedule

Businessman with a Gantt chart

This article looks at a simple, practical approach to creating project schedules. After reading this article, you will have a sound approach to creating schedules that you can use for future projects.

Resourcing Project Managers

Project manager jobs advert in a newspaper

Ironically, although resourcing production team members is a significant part of a Project Manager's role, very little focus is placed on resourcing the Project Managers themselves.

Learning from Project Failures

Success and failure directional signs

Some of the most important lessons we learn come from failures. Kenneth Darter explains a simple four step process to make sure the same failures aren't repeated.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Duncan commented on…
10 Rules of Highly Successful Project Management
- Mon 26 September 7:50am

John Corbett commented on…
10 Rules of Highly Successful Project Management
- Mon 19 September 1:36pm

London Management Centre commented on…
Get Maximum Benefits of Merging Top-down and Bottom-up Project Management
- Mon 19 September 11:29am

Latest tweets

General Project Management • Re: Software Product Delivery Plan for an Agile project https://t.co/qlwUTdDgAa #pm #projectsmart about 1 hour ago

General Project Management • Re: Best/cheapest online PRINCE2 Foundation course with exam included https://t.co/qRvyY1ZXVj #pm #projectsmart about 1 hour ago

Here are some basic rules of reporting status that you can use to further your reputation https://t.co/eOfIohem8R #projectsmart #pmot about 13 hours ago