An agile project is a temporary endeavor undertaken to create a unique product, service, or result, in which requirements are not clear at the beginning and must be progressively elaborated from the continuous stakeholders’ feedback (=value) who attend to project reviews to see working product increments regularly.
In an agile project, after each iteration review, project stakeholders openly state their thoughts on the increment they’ve just seen. The product owner uses this feedback to validate requirements –in agile we prefer the term user story– or to reduce uncertainty. This way of moving on projects is called «value driven lifecycle».
For those projects in which requirements can be agreed early on, such as engineering and construction projects –a.k.a. EPC projects– following a value driven lifecycle is considered a methodological flaw. The correct way is to follow a plan driven lifecycle –a.k.a. predictive or process driven lifecycle– consisting of agreeing on requirements in the first place, and based on that, elaborating a scope baseline to estimate the schedule and cost baselines, to finally get a project management plan, including the rest of project management knowledge areas: quality, resources, communications, risks, procurement, and stakeholder management.
When project requirements are cannot be agreed upon initially, given the huge uncertainty at the beginning, quite usual on software projects, it is considered a methodological mistake to follow a plan driven lifecycle. In this case, the correct way is to follow an agile lifecycle –a.k.a. adaptive, change or value driven lifecycle. First, we decide how long the project is going to take, and also the cost of a stable team, and then we divide the project into sequential releases to be closed in about 2-3 months. Inside each release, we follow sequential iterations taking the same duration –timeboxes are typically 1-2 weeks long– ending up with a demo to stakeholders of the new product increment. Stakeholders’ feedback allows us to validate old requirements and estimate the new ones. We can say the scope is progressively elaborated.
Any project may apply an agile lifecycle or predictive lifecycle in any particular phase or release. When that is the case, we say the project is following a hybrid lifecycle.
Professional project managers are usually proficient on predictive and agile project management methodologies. They are supposed to have a practical knowledge on tools and techniques to get any project to meet the project management goals, mainly to finish on time and on budget. Obviously, there are many factors causing the project do not deliver the value or do not meet the project management goals. Then we say the project is a failure and the project manager is usually considered as the prime responsible. Good project managers document failure evidence not at the end of the project or phase, but on each project review, so that everybody may anticipate potential issues and get involved to find corrective actions before is too late.
Most of the times, it is unfair to blame the project manager as the only accountable of the project failure, but managers think the other way around: managers usually want us to get the blame.
Managers want a PM on top of the project to get somebody to blame if project fails 🙁
When you know this is the name of the game, then you play better. Professional project managers want project review meetings and project status reports. These are our tools to report how the project is doing, but also to get project steering committee members engaged: we want to involve them in the problems and seek the solutions with them. If we do like this, everybody understand the project is own by the performing organization, not by the project manager. The project manager is not the only one to blame, anymore.
No rules for Agile Projects?
Whenever managers authorize a new agile project in the organization, a kind of cognitive dissonance come to their minds:
- On the one hand, they want the project meets the management goals and deliver the expected value. That is, they want the project on time, on budget, and meeting the project requirements, the same as any other project.
- On the other hand, they know the team should self-organize. Team members take their own decisions and, when they have any doubt, they should ask directly to business users. So, what’s the point of having a project manager in an agile project?
Think of the most representative example of the agile model, that is, software projects. There is a disturbing complacency about failure. We are used to statements like «I’ve seen no software project delivered on time, on budget».
Do you really think this a problem without a solution? If we let the team do their tasks but nobody is accountable for the project, why is it a surprise when the project ends up with schedule slippage and cost overrun?
Agile projects must also be controlled. Managers have the right to ask for progress and forecasts. Somebody should be there to answer about project status properly, to manage potential problems before it is too late, to prioritize features, to help team building, to manage stakeholder engagement, etc.
Big organizations have more and more projects with unclear requirements. Management is more complex when these projects need to be managed under programs or portfolios. There is no silver bullet, but when finding solutions to problems related to projects, professional project managers should play a key role.
On May 31st we shared a webinar introducing the challenge of agile projects. Recording (Spanish) is available at: https://youtu.be/JhFxKRPDppQ
Join our next free webinar (in Spanish) on June 15th at 18:00, Spanish time. We will show in practice how to control any agile single project and also agile programs and portfolios, with PMPeople tool.
Webinar link: https://youtu.be/1zhp3pvtkH0
To download the presentation (PDF) click here: https://bit.ly/2QGGHAi
Presentation includes:
- How to apply The Agile Manifesto to Projects?
- How to scale Agile Projects in big Organizations?
- There’s something about Software…
- What Managers really meant when they “empowered” me as the Project Manager?
- A Real Agile Project: PMPeople Development
- Agile Case Study, by Mike Cohn
- Demo: Agile Case Study with PMPeople
PMPeople is the tool for the project economy. It is aimed to unify professional project management by these differential points:
- Designed by and for professional project managers, following professional project management standards.
- Online productivity –less meetings, less documents, less workflows– through distributed collaboration among 12 specialized roles: Organization Owner, 6 roles on demand management and 5 roles on supply management.
- Freemium product –unlimited time, unlimited users, only managers have to pay– usable via web and mobile application.
Start using PMPeople for free, for unlimited time and for any number of users. In premium organizations, only managers have to pay. Several roles –stakeholders, team members, sponsors and resource managers– are always free. You can increase or decrease your premium seats according to the organization actual needs. Premium organizations have access to our interactive support through Slack. Our servers are located in EU. This software can also be hosted on customer premises.
