Project Management

Project management: One size does not fit all

Some projects are not suited to a Waterfall approach, and they're not a perfect fit for a 100% Agile approach. The solution might be a combination of the two project management methodologies.

Whenever I see a hat or item of clothing that has to go over my head labelled "One Size" I know it will not fit me, because I have a big head. I also know there is rarely a perfect fit for project management (PM) methods unless they are tailor-made. But, just as with clothing, few companies have the budget for the tailor-made PM option. This just means we have to learn how to choose our PM processes carefully.

Many projects are not well-suited to a traditional Waterfall approach because the end-product cannot be fully specified and documented at the outset. These projects are not necessarily suited to an entirely Agile approach either, where it may not be desirable, or even possible, to deliver "bite-sized" chunks at regular intervals in order to refine what the end product will be. Even certain large, complex IT projects are ill-suited to an Agile approach because they require a measure of discipline and control.

As PM and the Agile approach matures, it's becoming clearer that some projects require traditional PM combined with flexible PM and often something else thrown into the mix; this might be internal processes developed for a specific organisation, or a project manager's experience in knowing what methods deliver successful outcomes.

For many projects, the answer to the question "Which PM method is the best fit?" is not always clear. This is especially true for projects that are breaking new ground or using cutting-edge technology in a fast-paced environment.

But just how easy is it to combine traditional and Agile methodologies? First, it is important to select a core method from which processes can be removed or added as necessary. Without a core method, there is a risk that the project could descend into chaos and that those involved would not understand what is expected of them.

The case for a core Agile approach

The fact that Agile project management is based on iterations should immediately indicate whether it is suitable as the core approach for a particular project. Clearly, you cannot build a bridge or a railway using an iterative approach, but a less tangible product such as a new business process or a software system (which can be subject to user testing and refining) is well-suited to an iterative approach. Each iteration is likely to be over a relatively short, finite period of no more than several weeks (although this depends on individual projects) and deliver a completed package that can be tested standalone.

Bear in mind that this isn't as easy to implement in complex scenarios where inter-dependencies come into play. Even in projects classically suited to Agile methods, it has its disadvantages and may need to be adapted to work effectively. Another major disadvantage with an Agile approach is not being able to estimate costs upfront; if you cannot describe exactly what will be produced and when, then it is difficult to provide an accurate cost estimate. Agile proponents would argue that costs for a traditionally managed project rarely come in on budget anyway.

The case for a core Waterfall methodology

Waterfall is the traditional, and more formal, PM approach and has a series of defined phases to be followed in chronological order, so it imposes discipline on the various project tasks. The Waterfall method assumes that the final product can be fully specified and designed in the early stages of the project and is well suited to major engineering and building projects or projects that require strict regulatory control.

Its advantages include being able to: document what will be delivered in advance, assign adequate resources, and provide a detailed schedule of tasks. It also ensures that costs can be estimated upfront, which is essential for commercial projects for external clients.

Using a Waterfall method means that everyone involved in the project understands where and how it is going and what will be delivered and when. Risks and changes are all documented, controlled, and communicated so they can be well-managed, which is essential on large, complex projects, particularly when they involve disparate teams.

The case for combining Agile and Waterfall

Many internal PM frameworks combine methods without specifically recognising them to be from another method. Major organisations I have worked with have used an "iterative Waterfall" approach to software development without acknowledging any debt to Agile. Similarly, some Agile projects introduce communication plans or document tracking processes where detailed documentation is a necessary part of delivering a completed product.

In many of today's complex business environments, projects require control and flexibility, which is why a combination of PM methods that offers both can work well. In essence, it is irrelevant how you describe which method is being used -- what is important is that you understand the elements that are necessary to complete the project and when each task will be completed. You will either have to settle for a less-than-perfect fit with a standard methodology, adapt the most relevant methodology, or combine traditional and Agile approaches.

The evolution of PM

PM continues to evolve as more is learnt about why projects fail and succeed, and this evolution will lead to further changes. These changes may happen slowly, but I like to think that a more intelligent way to manage the complex projects our business worlds present to us will surely evolve.

About

Michelle Symonds has many years of experience in IT and IT Project Management in the oil industry and investment banking, working on complex global projects and managing overseas project teams. She is now a freelance consultant working with a Project...

30 comments
Mike178
Mike178

Hi Michelle,

You have raised a very essential and important point here. A lot many teams fail to realize the nature of their projects before implementing any of the project management tools out there in the market. I am sure with the help provided here, teams all around would benefit a lot more.

Cheers! :)

sherry23
sherry23

Hello All, Yes, We had same problem from IT team we have hired them in house...we do have around 50 computer machines and every day something get wrong and repeatedly, despite having IT team. Finally, we are thinking get into third party contact for IT Services if anyone have any good company please let us know and someone suggest me this company is best, however i have put it here : http://www.fortishosting.net/desktop-servcies-support-london Thanks Sherry

ProfessorBlaize
ProfessorBlaize

I see Waterfall as attempting to pre-specify deliverables, costs, and timelines, which gives the project governance team some comfort. Agile allows a project to learn its way towards the outcomes, which is great for uncertain environments. I think you can combine these by using some of each of the principles, but not all of each, For example, if you want to specify a new business process, the waterfall principle would ask that you set goals, rough timelines, cost parameters - in other words specify what the vision is for the finished process and what it is worth to fix it. After that planning work is done to get everyone on the same page, you can use Scrum methods to chunk away at the pieces of the problem to keep everyone involved and focused. You might have to go back to the plan and revise it, but at least you have a set of agreed-to targets.

a.pyne
a.pyne

This is really frustrating. This article makes some great points but also some real howlers. How many more times does it need to be stated that Waterfall and Agile and NOT project management methods but development methods. One great point but a truly obvious one is that one size certainly does not fit all when it comes to either PM or develop methods. Else Tech Republic would not exist for one thing. The trick then is to find the right project management approach suitable for your project. Professional PMs and for that matter, professional IT people, engineers - well professionals period - ADAPT good practice. Which could mean combining Agile or Waterfall or whatever. And usually means adapting PM best practice. I cannot recall a single project over 30 years where the "book" was used. PMI PMBoK after all is NOT a cookbook. I ( and clearly with others) recall doing interactive waterfall in the past. for me it was 30 years ago - we just did it and did not really know what to call it - we were just being professional. Damn, should have written a book and made millions! To date I have never seen an Agile PM method. I have seen PMI, even Prince/2 adapted for Agile IT projects. But never a true Agile PM method that is CLEARLY different from PMI, PRINCE/2 etc. So lets be clear, there are PM methods, and Development methods......etc. But they are different, designed for different purposes and often need to be combined. But thats it. Have fun!

blhelm
blhelm

In my 32+ years of working in the IS/IT Industry I have never found another PM methodology that works for an infrastructure project better than straight waterfall. 1. Requirements Phase - What is the business need, what are the primary drivers, what will be the measurable success criteria 2. Design Phase - Matching specifications to requirements (capacity, capability, functionality) 3. Estimating Phase - How much time is it going to take, what skill sets needed and their availability, RFP's from vendors and sub-contractors, how much is it going to cost, is it even feasible 4. Procurement Phase - getting all the hardware ordered, signing contracts, software licenses, lining up schedules 5. Deployment Phase - installation, configuration, testing, change management, deployment None of these phases can possibly be iterative. Not taking everything into account during the previous phase risks delays, conflicts, incompatibility, cost over-runs.... Very few companies purchase excess capacity, capability and functionality to accommodate an unknown perceived need or set of requirements. There is no ROI formula that I have ever seen that factors iterations into the cost benefit.

DBRem
DBRem

While many of your points are valid, this is not a "project management" issue but a SDLC (Software / System Development Lifecycle) issue. The distinction between different approaches of Software Development are important and varied, but how that effort is managed (Project Management) isn't necessarily different - Project Management sits "over top" the SDLC and arguable can be the same independent of the SDLC. Now in reality, Project Management will be performed differently to some extent with a different SDLC, but that is primarily a function of the SDLC as opposed to a project management issue. Think of the SDLC as "how we develop the software / system" and PM as "how we manage the software / system development". The crux of the article is correct though; choosing an appropriate SDLC based on the nature of the project is important, as is understanding the differences in SDLC in order to make an informed decision or recommendation for the SDLC.

dittouk
dittouk

Get me some spaghetti and a marshmallow! Tony, "educating" stakeholders brings me onto another topic - the importance of soft skills/people skills in a project manager. With the right soft skills I believe a PM can change the thinking of others involved in the project.

dittouk
dittouk

I think the assumption that a project plan is devised at the outset and can never be changed is a failure of the PM to "educate" clients, stakeholders, end-users about the realities of many projects. Even in a traditional PM environment (whatever that is these days!) it is important to recognise and expect change to the plan as well as the scope.

xxing14
xxing14

Welcome to http://www.likesurprise.com// where is the most popular Panthers online shop. We are professional supplier in wholesale Panthers shoes,clothes,bags and so on. Once you visit our website, you will be find many many surprises in our site. Newest stuff will be selling in our website in the first time. michael kors handbags cheape, cheap air force ones and so on. Welcome worldwide customer visit our site and buying online. Let us make thing more easier at http://www.likesurprise.com//

parallelproject
parallelproject

Tony If you have a fixed price contract then the waterfall approach works well because the first phase is to define fixed set of requirements and scope. The supplier can then provide a definitive estimate for this work. With agile I struggle to see how this could be supported by a fixed price, competitively let contract.

dittouk
dittouk

Thanks for the comment Kevin - I was thinking about IT projects that involve re-writing, for instance, back-end library routines that are used across a wide range of existing applications. Changes can't always be tried and tested quickly and easily enough simply because the changes are so widespread and there can be many diverse departments, end-users and stakeholders affected. You might know what you want to deliver and have well-defined parameters - same functionality, faster, maybe - and need to be sure the changes have no detrimental effect on existing functionality.

kevin
kevin

" Even certain large, complex IT projects are ill-suited to an Agile approach because they require a measure of discipline and control." This implies agile has no disciplne or control which is the opposite of my experiences using and applying agile methods.

pnaybour
pnaybour

Hi A very interesting article, but how can these two approches be combined when the project is delivered using a fixed price contract. I can see this working for a waterfall or a agile approach but what about the two methods combined.

Tony Hopkinson
Tony Hopkinson

First PM article I've ever seen on this site, that even intimated that you should choose a lifecycle based on the project instead of deforming the project to meet a pre-chosen lifecycle. Congratulations Now all we need to do is get you up to speed on life cycles other than the two you know. :p

africord
africord

One could argue that versions of the iterative waterfall approach predate Agile. As such, they would have no reason to acknowledge Agile. The Spiral Development Method dates back to 1986. The Agile Manifesto was not created until 2001. I used the Spiral Development Method during the 1990s. It was a challenge to fit it to traditional project management tools of the time.

Tony Hopkinson
Tony Hopkinson

I believe they could as well, don't have to take my mittens off to count the number of times I've seen it happen though.

Tony Hopkinson
Tony Hopkinson

teach them. It was the results of waterfall that gave us Agile, the mindset that likes to know what you are going to get and what it will cost on day one is alive and "well".

kevin
kevin

I agree, the problem I see is its often the PM that seems to need educating first.

Tony Hopkinson
Tony Hopkinson

The problem with waterfall is the assumption that nothing is going to change over the lifetime of the project and so change requests always add to the cost. If they don't then you are being agile and all you have done is done all your analysis and design up front. The next problem is when negotiating the fixed price, in nearly every case I've been involved in. The first price is always too high, so what do you do, knock quality out by reducing contigencies using the crossed fingers approach, use cheaper people etc in order to get the job. Not all fixed price contract development will fit Agile. There needs to be some form of iteration / phasing inherrent in the project. The main thing required to do it is the purchaser understands that they've bought X amount of effort to be spent on the results they want. One project I did like that (Spiral methodology, but you could describe that as agile), was optimisation of a manufacturing process. We made it better, it cost X and saved Y. Based on that we worked out cost and saving of the next iteration. We stopped improving it when the cost of doing so was greater than the benefit. It's all about how you define the expectation. Instead of saying you will improve productivity by X at Cost Y We said we will improve productivity by more than Y.

kevin
kevin

Hi dittouk, do you think these projects have come about due to a waterfall approach or an agile approach?..the agile XP disciplines which in my opinion must be followed to prevent the creation of a legacy system should mitigate this; we should not be afraid to change components of a system as long as TDD/unit tests have been done, the team(s) understand what DONE means and they are disciplined enough to always get DONE and not cut corners due to time pressures..rather follow the preferred agile approach of flexing the scope. What i am getting at here is its not having discipline in the first place which tends to cause the legacy issues, I know I have worked both ways for many years and by far the most disciplined approach to any software project has been when the agile practices have been followed.

Tony Hopkinson
Tony Hopkinson

Usual problem is while implementation is agile enough to react to changes in expectation, the change in expectation itself has not been properly communicated. e.g. Drop feature X, do feature Y. Okay Where's X then?? Huh? So they are almost saying we've been a bit too agile, and the business would like motre oversight before we react to what they say they want now.

Tony Hopkinson
Tony Hopkinson

Waterfall you would or would not deliver for the fixed price. Agile you'd deliver a fixed amount of work, which might or might not meet the original scope...

Tony Hopkinson
Tony Hopkinson

Agile development mentions concepts like TDD, Agile Project Management does not. In fact a lot of Agile PMs will drop TDD, unit testing et al, in order to make their plan achievable.

Tony Hopkinson
Tony Hopkinson

If the "official" scope can't be modified as the project evolves, then it's not Agile.

kevin
kevin

"yet it's not allowed to." then its not agile, I think this is what you are saying Tony?

Tony Hopkinson
Tony Hopkinson

Business missing the point of Agile a lot. They do a plan up front, and then try and make implementation meet it, no matter what. The plan can't change, because that's where all the initial expectation was set. Agile is about changing the scope as required in order to deliver. That means expectation must change, yet it's not allowed to. Set in stone at project inception with even less discipline than if waterfall had been chosen. Not agile, QAD... In order to meet a fixed expectation, quality gets dropped, no different to waterfall in terms of out come.

kevin
kevin

thats the concern when you are more worried about the plan than the delivery of the value you end up with poor quality software and a legacy product. Do you think the PM's miss the point of agile practices in this case?

Editor's Picks