What do the Great Wall of China and the Apollo Missions have in common? Decades of planning, thousands of workers and the gross amount of money.
Any one of them could have been a massive waste of everybody’s time and efforts, but miraculously, they weren’t. Such massive feats were planned and executed with what we can consider colossal first steps of project management.
Project management essentially draws out a road map for getting from point A to point B – from planning to grand opening (or release). Project management methodologies are approaches by which to organize, manage and control a project, so that it delivers the right outcome, on time, and within budget.
Where do you come in? Well, you come in with the methodology that has best served projects similar to yours. Take a look at the 4 most popular methodologies, and choose the one that suits your needs.
1. Traditional – Waterfall
- Do you work with fixed requirements and a clear picture of what the final product should be?
- Is your team very experienced to deal with heavy-weight specifications to produce high-quality projects?
- Are delivery date and budget your be-all-end-all?
You might be looking for the Waterfall methodology. It was originally implemented in highly structured physical environments where changes are expensive, and often impossible. This used to be the manufacturing and construction industries, but Waterfall has been well received in software development projects more recently.
The Stacey Graph gives clear insight about when Waterfall method serves the most. It points out that projects within the simple zone on the graph are the most Waterfall-friendly. It is the projects where both the customer’s requirements and the implementation technology are perfectly clear. It is preferable to have small teams for this.
The Waterfall method treats the project as a predictable whole that everybody is accustomed to. Phases are strictly sequenced, and when one is finished, it stays finished, everybody moves on to the next. The main source of trouble is when somebody decides to change the project requirements, as Waterfall is not at all flexible.
The level of control and pre-planning makes each project phase very distinct and recognizable, strung into an orderly sequence.
The Waterfall Phases:
- Requirements – The Pre-planning phase. It is imperative to get very clear instructions before anyone starts working. The end goal is clearly visible to the whole team.
- Design – Meticulous plans are drawn before things get practical. Documentation and paperwork in general are completed in this phase, and each subsequent phase will strictly follow this documentation.
- Implementation – The dirty work. Highly skilled teams create the project top to bottom, in perfect harmony with all pre-made plans.
- Verification – The finished project is inspected, and compared to what the customer ordered. It has to be the same thing, completed according to project specifications.
- Maintenance – The project is good to go. The development team is still in touch with the project via regular maintenance – should anything leak, they are there to promptly fix it.
- Adequate resources and detailed task schedules are assigned thanks to meticulous documentation delivered in advance. This also means that all costs can be estimated upfront, a must for all commercial projects.
- Every member of a team managed by the Waterfall method understands the project perfectly – the whens, the hows, the whys.
- Progress is easily measured. The customers and the developers can agree on what will be delivered earlier thanks to straightforward planning.
- When customers hand in their requirements, there is no reason for them to stick around. This gives them room to do their own thing while the developing team works uninterrupted. The customer then only needs to be involved with status reviews, approvals etc.
- It is hard to prepare requirements so that the customer understands them. Details intimidate them, but they have to be out in the open before the Implementation phase.
- Customer satisfaction is not guaranteed. There is a difference between documents and deliverables, and the customer may not see the finished project until it is mostly finished. And again, changes are expensive, if not impossible.
- It is hard to distinguish or fix problems and inadequacies when the testing and feedback phase occurs so late in the process – too late you might say.
- Do you expect your project requirements to change rapidly, making it impossible to be 100% clear about the Big Picture?
- Is your development team skilled, adaptable and independent?
- Do you value customer feedback?
The Stacey graph from above shows that complexity enters the zone of anarchy on highly creative processes. Waterfall doesn’t work here, because most of the time, your only comfort comes from an iterative process capable of containing risks within a defined timeframe, for continual inspection. Problems are solved within their iterations, and everything can move on.
This Agile project management works best with new or rapidly evolving business environments and for highly complex situations, where managers feel around until they find the optimum business model. Thus, Agile is most often found in the ever-evolving software and IT industry.
This iterative project management relies on collaboration and response to change. Phases are no longer a sensible, preset sequence, but smaller iterations which can all be shipped out for feedback and necessary alterations, until you reach the final goal.
Defined in 2001, Agile remains a concept rather than a full-fledged methodology. Its implementation is best performed through existing project management frameworks such as Scrum, Extreme programming, DSDM, and Crystal.
There are 4 values which form the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These values are implemented through the following 12 principles.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done – is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Shorter planning cycles leave room for evolving requirements and prompt changes.
- Customers and clients can actively provide feedback, which makes it easier to build the product that actually solves their problem.
- The preference for team involvement and communication leads to faster discovery of progress and obstacles.
- The project evolves rapidly. Each problem is only a stepping stone to a better solution in the next phase.
- Costs cannot be estimated upfront. They are generally hard to estimate at any point, when the product requirements change as often as they do.
- All this customer involvement will get you down. On the other hand, some customers may not have the time or interest to participate as often as they are called upon.
- Agile projects are frequently reprioritized, and as such, it is nearly impossible to deliver within a preset timeframe.
- Additional phases often happen, piling in the costs. Customers can also add to these costs, when feedback inspires them to make new requests when the project has already started. This, too, prolongs the project timeframe.
- Do you agree that if a feature does not add value to the customer, it is disposable?
- Is your project fixed in a place or often repetitive, so that the processes and activities are standardized?
- Do you consider delays and waiting times waste that needs to be cut off?
The Lean methodology comes from the manufacturing process. It was developed by Taiichi Ohno, while he was working on enhancing the production systems in Toyota. He took inspiration from the Ford production line and American supermarket supply management.
But the term “Lean” was coined in 1987, to describe the efficiency of Toyota’s production management. J. Womack and D. Jones formed the “Five principles of lean thinking”, as applicable to projects as it they are to manufacturing:
- Identify Value – Find the excesses of a project. Usable customer value is placed ahead of features, functions and requirements. Should you even be working on this project? Does its end goal bring value to both the customer and the business? If not, then skip it.
- Map the Value Stream – Find which steps are obligatory, and cut away the rest. Delegate the project to teams so that there is no time lost at handovers, and bottlenecks are entirely eliminated.
- Create Flow – Cutting the project into smaller, standardized tasks, and direct them to flow speedily towards the customer. You create flow by monitoring processes to identify obstacles and remove them.
- Establish Pull – The customer is very important in the Lean methodology. They get to decide what is and what isn’t valuable. Decide late; deliver fast – don’t proceed with ideas until the customer greenlights them. Queue up completed work until it is necessary to send it out, for the value it will provide at that moment.
- Seek Perfection – Repeat the first 4 principles, pursuing the perfect project cycle.
Lean has been adopted and implemented in many industries. But like Agile, Lean is a concept best implemented through the tools and frameworks of Kanban, Six Sigma, Lean software development, etc., tailored around the needs of various projects.
- Tasks are evaluated for their benefit for the customer, and their financial opportunities. Anything short of fresh and valuable is cut off. Unnecessary steps in the process are also cut off. The identification of value adding activities downsizes the scope of the entire project.
- Value Stream Mapping visualizes the whole process. The big picture overshadows individual needs, effectiveness is paramount.
- Cutting off the possibility for obstacles smooths out the project process. This means that the product can be delivered in a shorter time using fewer resources – efficiency and customer trust.
- Value is only defined by the end customer. Things get complicated fast in projects where there are multiple end customers.
- The value stream only functions when processes are fixed in a place or repetitive, so that it can be standardized. Mapping processes unlike these would be expensive and dispensable.
- It is hard to find a Flow in projects. Manufacturing easily becomes a unidirectional, standardized routine, but project iterations can go back and forth and all over the place. Projects are much more complex than a production line – there are iterative loops, risks and uncertainties.
- Is your project carried out in a very tightly controlled environment?
- Are you the government?
PRINCE2 (Projects IN Controlled Environments) project methodology is extremely widespread for a methodology so strict. It was created by the UK government for use on internal projects. These were most often both public and private sectors, such as police forces, telecommunication, banks and other large commercial organizations.
PRINCE2 is made up of proven best practices for project management. It can be used outside of strict government projects as well, and implemented in similar situations in different industries: construction, engineering models, IT, business, financial or product development lifecycles. PRINCE2 aims to meet the requirements of the entire management team.
There are 7 processes within the PRINCE2 methodology, and all of them need to be addressed by the project.
- Starting up a project – Check whether the project is worthwhile before you take it. The Project Mandate must define the business need and expected outcome of the project.
- Initiating a project – Plan out your project in detail, and produce a PID – Project Initiation Document.
- Directing a project – In the entire duration of the project, the Project Board manages and monitors processes with reports, and guides through decision points.
- Controlling a stage – A Project Manager monitors and controls activities, including the way work is authorised and received.
- Managing stage boundaries – Key decision points are presented to the Project Board, which then decides the project’s future, and kills off projects that have overstepped their tolerance level.
- Managing product delivery – The delegation of work packages between Project Managers and Team Managers is overseen. Work packages are delegated down the hierarchy, and results are evaluated up the hierarchy.
- Closing a Project – The project is closed with an in-depth analysis of processes, results, and reception. This report also has to be approved by the Project Board.
- PRINCE2 is a means to keep the environment controlled for projects that exist in controlled environments.
- There is zero tolerance for mistakes, and communication is entirely essential.
- The stakes are high and the process is overseen in its entirety. PRINCE2 can only work in an environment where authority is unequivocal.
- PRINCE2 has a very straightforward structure, and as such, it can be tailored to fit projects of any volume.
- It seems intimidating when misunderstood or misapplied. Such a dominating methodology takes time to absorb and truly implement.
- There is room for bottlenecks as team members wait on quality checks. The strict hierarchy does not work for everybody.
- There is literally no room for risk in a PRINCE2 environment. No risk, no profit.
It is important to stress out the fact that one size doesn’t fit all and that each one of these methods are guidelines rather than strict set of rules to follow.
The real benefit comes from being able to tailor the right method to your project’s needs.
We will write about each of these methodologies in details with lot’s of real life examples. If you want to be notified when the next article is published, sign up below.