It´s not just the trend period itself but also the mechanism how a trend gets socialized in organizations that is repeating itself decade by decade: Often the small players start to explore these trends, then the relevant media jumps up, the consultants adjust their service portfolios and the big players try to adapt with it. By latest it brings promoters and critics on stage – a war of faith seems to have broken out. At the end – like in real fashion – the new top trend it is tried out and worn down until it goes ‘out of fashion’ and is finally ‘out’.
TOP TREND – AGILITY
So today we´re in the midst of this Agility hype. Everything needs to become and everybody needs to be agile – agile product development, agile production, agile teams, agile HR, agile Leadership, agile you name it and also Project Management has to be agile. Let´s have a look at a few good practices in (classic) Project Management in times, in which one must feel ashamed practicing the classical “waterfall project management”.
NOT EVERY SINGLE PROJECT NEEDS TO BE “AGILE”
Having personally run quite some bigger projects in my professional career I can state: It doesn´t matter whether it is waterfall or agile, classical or the other way – it has to fit!
1. When it comes to setting up a new production line to fulfill the committed ramp up volumes for a customer contract you don´t want a “minimum viable product (in line)” at the end.
2. When you are refurbishing an aircraft cabin which has a scheduled and fixed re-entry into service date you can’t come up with a prototype ready for front stage testing with airline passengers prior to the next iteration – by the way: When safety first matters, minimum viable products, front stage testing & iterations might become an issue!
3. And finally: As Agility according the Agile Manifesto is by far more than just implementing some methods like Scrum, you might fail with an agile project management approach when the predominating leadership culture is still a conservative one – e.g.: The TOP Management still expects you to provide project reports with traffic lights (most likely green ones) and does not really delegate ownership & responsibility including the decision making power at the lowest possible level.
In many cases it is quite sufficient to limit oneself to the exercise of the basics of good old project management like described in the “Guide to the Project Management Body of Knowledge (PMBOK® Guide)” and to apply them consistently.
A FEW BASICS THAT ARE GOOD FOR ANY PROJECTS
Here are 8 checkpoints / minimum requirements with agile spots in it which are already good for every single project – you might use it as a simple checklist to assess the maturity of your projects.
- Align on the SCOPE OF A PROJECT in written format with a named PROJECT SPONSOR – define deliverables, due dates, budget restrictions
- Nominate ONE PROJECT LEADER – “non or double headed” projects are sure of only one thing: they fail because there is no one responsible at the end.
- SLICE THE ELEPHANT – develop a manageable (work breakdown) structure for the project. If you think a “work breakdown structure” is too old fashion just call it a USER STORY as the agile people do – but it remains a sliced elefant which is good for the project success 🙂
- Get your TEAM MEMBERS ON BOARD and clarify roles & responsibilities within the project team
- Be aware of the major PROJECT STAKEHOLDERS and set up regular communication formats (inside and outside the project)
- Be aware of the major PROJECT RISKS, define mitigation actions and monitor risk developments continuously
- DON`T MEET – instead: establish regular project status dialogues – the more frequently the better – the shorter the better, e.g. 15 minutes every second day at a fixed time. Therefore continuously provide TRANSPARENCY on project scope, tasks, responsibilities, due dates and achievements, risks & stakeholder concerns. This can be done with or without software – agile people use Sticky Notes – however: just do it!
But in any case stop doing “chicken chicken chicken” in your (project) meetings. If you don´t know what we mean by that and because we love it so much – here is again Doug Zongker’s “Chicken chicken chicken” presentation on Youtube. Enjoy it but don´t do it yourself!
- DELIVER IN SHORT CYCLES – “…from a couple of weeks to a couple of months with a preference to the shorter timescale” as stated in one of the twelve principles of the agile manifesto.
We´ve seen a lot of project plans that were designed along the lines of Concept Phase, Preparation Phase, Implementation Phase, you name it Phase. Get rid of these! They are too abstract, Gannt-charts overlapping several months even years and we´re bored by seeing colored traffic lights! Welcome to new work(ing methods)! Agree on short term deliverables. It is well known that every major project begins with the first step(s) – Just start doing it! What is important for the next 4 weeks? Which are the three to five things we will have accomplished by then? And whom / which support do we need in order to achieve this?
You think that’s all banal and nothing but project management trivialitiy? Sure! But when it comes to reality of project management we often observe how (fr)agile we are in fulfilling these minimum requirements or “good practices” of project management.
Finally there is at least one thing in common for both approaches – the classic and the agile way – which is:
So – instead of beeing (fr)agile in running your projects we recommend to better focus on and be disciplined in applying the 8 checkpoints mentioned above.