Jun 1, 2018
I got a text from a mate of mine the other day that made me laugh.
It read:
<BEEP>> I hate sprint planning. I wish they’d just speak English and act like grown-ups. You don’t need << BEEP >> lollies and chocolates to have a meeting!
Now bear in mind this guy is a vastly experienced project manager and has rescued more than his fair share of large complex projects. He’s the sort of guy who runs at fires, not away from them. Right now, he’s in the middle of an inferno and in large part it’s due to an inexperienced delivery team and an ill-conceived belief that blindly following the agile playbook will deliver the desired business outcome.
Holistic View
But that simply isn’t true. Delivery isn’t about adhering to the agile framework. Nor for that matter is it about stubbornly adhering to traditional waterfall models. It’s about taking an agnostic and holistic view of the environment and of the problem being faced and applying the best approach and tools for that situation.
This is not to say that prescription is a completely bad thing. Especially when the pitfalls of delivering something another way are clearly understood. But what I am suggesting is that dogmatically following specific methods may not always be the best fit with the environment. In short, the ideal conditions for agile rarely exist. The reality is that distributed, large or cross-functional teams, outsourcing (in particular offshore) and limited availability of key stakeholders and critical resources, means that projects frequently operate in sub-optimal environments.
Optimal Agility
Now don’t get me wrong. I strongly advocate setting up projects for success from the start. But when the environment doesn’t allow for optimal agility then we need to be as effective as we can be. This means maximising the benefits of agile despite having to make compromises. After all, every individual, every team, and every organisation is unique. And because of that context matters. And that means we need to adapt and evolve our approach for each situation we face. Key to this is allowing teams to own their own processes and to modify how they attack a particular problem within the constraints of the environment in which they’re operating.
It doesn’t matter what different roles are called and whether a meeting is a stand-up or a retrospective. What does matter is whether the output from the activity is delivering value to the business. And that the team (or squad) is taking accountability for that delivery and supporting realisation of the benefits underpinning the business case.
Pragmatic Agilist
Pragmatic agilists champion agile whilst at the same time dealing sensibly and rationally with environmental constraints based on practical experience rather than theoretical considerations.
Recently I’ve witnessed a wave of dogmatic agilists and they typically share two common characteristics; they have only ever worked within an agile framework and they will compromise the agile principles as long as the framework is maintained. That resistance to flex and to adapt is itself contrary to the agile principles. Pragmatic agilists on the other hand, are most likely to have had experience of multiple frameworks and are open to modifying their delivery framework to test and implement new ideas in order to maximise value for the business.
To achieve the best outcome for the business we need to value pragmatism over agilism. That doesn’t mean we don’t value agile. It just means we value pragmatism more.
Just forget about the chocolates!
May 18, 2018
Twenty-five years ago, a mate of mine made a colossal mistake. As a civil engineer in his first job out of university he designed a bridge that didn’t join up. Now for all of us who were his mates, this was a great laugh. For Mark however, this wasn’t so funny. And it was a long time before he was allowed to submit another design. But he never made the same mistake again. Conversely, we in the technology game are slow learners. Perversely, it’s almost expected that root causes that have plagued projects in the past will manifest again in new projects. Even more interesting is that regardless of whether the project has been delivered under a traditional waterfall model or whether it has been delivered under an agile framework, the same root causes are commonly found. Here’s the top five from my experience.
Scope Creep
In my opinion the most common root cause in troubled projects. However, scope creep is often driven by people, not technology or process. Having all decision makers in the room at the start of the project to define the scope is the single best action that can be taken to avoid future conflict, misalignment and unforeseen changes. The second-best thing is to ensure that all critical stakeholders are acquainted with the product or service being implemented and are cognisant from the outset of any limitations.
Poor Project Planning
I’m hearing more and more that planning and scheduling are no longer required for technology projects. That they’re a relic of the past that constrains flexibility and imposes unnecessary overhead to the project. Recently, whilst executing project health checks for a client, I’ve heard from more than one project team; ‘We don’t do project schedules. We’re agile!’. What transpired was that each and every one of those projects required rescuing. They had misinterpreted the fourth value of the Agile Manifesto, i.e. ‘Responding to Change Over Following a Plan’ to infer that planning is not required. In fact, there is no reference in the Manifesto to abolishing planning. Quite the contrary. Agile is not an excuse to ‘suck and see’. Planning is critical for agile projects. But don’t build a granular single master plan from ‘soup to nuts’ and take a punt that it will still be valid months later. Instead chunk it up in to smaller digestible portions using quality data inputs to create a highly reliable estimate, with a predictable outcome, from which you can test, review and quickly learn from the results.
Poor Communication
Lack of a project plan, an understanding of the delivery approach and the discipline to adhere to it frequently results in inconsistent communication and increased speculation and rumour. Poor communication practices are exacerbated in challenged projects due to team members’ uncertainty, denial and concerns about being held responsible. It’s the job of the recovery project manager to turn this around and instil a sense of confidence back into the team and protect them from any conflict targeted at the project.
Poor Engagement
Three key relationships need to be fostered from the outset of any project: Sponsor & Project Manager – this is the most important relationship. The sponsor should ‘ride shotgun’ and handle the business side whilst the project manager focuses on delivery. It’s imperative that there is a mutual trust between these two individuals. Sponsor & Stakeholders – there must be unequivocal clarity between the sponsor and the stakeholders around what is being delivered. Consistency of message and universal evangelism is critical to business adoption and enthusiasm around the end product or service. Project Manager & Delivery Team – this relationship is strongly influenced by the sponsor. The team must maintain trust in the project manager and know that he/she has their back. Avoidance of project fatigue is critical. Another very common problem is team member selection. Often the project manager is either allocated a team member or allowed to pick from a limited resource pool; rather than allowed to cast the net wider for individuals with the best skill set. Money is saved by using a cheaper resource … but that is soon eroded when the resource in question is unable to deliver against the schedule.
Poorly Managed Risks and Issues
Far too often risks and issues are captured in a register … and forgotten about. These need to be actively managed and measured from the outset with metrics around quantity, severity, age-profile being very good indicators into the health of the project.
But It Doesn’t Need to Be Like That
We don’t need to wait until the symptoms of these problems show themselves. They’re all very predictable. And because of that they’re also very avoidable. In fact, you only have to Google ‘Top causes of failure for ERP projects’ to realise that the problems, the impacts and the recommended approach to prevention are already well understood and documented. The key word here is prevention, as stopping the problem happening in the first place is far better than mitigating the problem to reduce its impact. So why do we as IT professionals think we know best? Why do we think we can beat the odds?
Ego … maybe. Inexperience … possibly. Lack of capability … perhaps. A more likely reason is poor initiation. The project hasn’t been set up for success from the start*. It is probable that the right people haven’t been brought together to define:
- What are the project’s scope, objectives and outcomes?
- What success looks like and how it will be measured?
- Who do we need to work with to get this done – both stakeholders and other initiatives?
- What are the quality expectations of the stakeholders?
- What are the key risks of the project and how will they be managed?
- How will the project communicate with stakeholders?
- What change management activities are needed?
- What are the project’s tangible and non-tangible benefits?
- How will those benefits be delivered?
- What are the specific tasks that need to be completed?
- What is our best estimate of how long these tasks will take and what they will cost?
- And given the above… do we have a valid business case?
(* See the recent article by Aaron Dowling for insight into Initiating a Project for Success).
By understanding the common root causes for failure and examining these at the very outset of the project, you will greatly enhance your likelihood of success.
May 11, 2018
So you have a valid business idea you are keen to run with. And you want to initiate a project to deliver this? You don’t want this to take an age but you need to get it right. At Luminate we work through a three step agile process to get your project up and running quickly while making sure it is set up for success.
Set Up
We start with a quick meeting to set up the Initiate phase. The meeting is with the Project Sponsor, is short – an hour or two at the most – to the point and aiming for a couple of key outcomes. (By the way if the Sponsor isn’t 100% clear and on board then you’re not going anywhere until they are).
Firstly, what is the Big Hairy Audacious Goal – BHAG- the project is going to nail? As in a Project Mission Statement but something with teeth. We need this clear up front so it can be used as a touch stone for the project team to refer back to as the project is initiated into delivery mode. If we can’t define this now that’s a clear lead indicator of project stress and very often project failure.
Secondly who do we need on our side to get this thing done? Identify the key stakeholders who need to be engaged NOW to help initiate the project. We’re not looking for everyone with a vague interest, we need decision makers and influencers. Start with a simple question… who are the people that could cause the project to falter if they aren’t on board? These are the critical stakeholders we need for the next step.
Outline
As quickly as possible we then get these critical stakeholders into workshops to agree on an initial business case . There will no more than 3 workshops and we are aiming to get through this fast so half-day or ideally full-day workshops are the aim. These stakeholders might push back, in fact at least some of them probably will as everyone is busy and we are asking for a good chunk of their time… but we help the Sponsor convince them of the need for their attendance.
The aim is to get the people we need in a room to quickly agree the fundamentals of the project. We need every genuinely critical stakeholder in the room or we will very quickly revert back to drawn out document circulation, and the dangers of offline decision making. Alternate representatives are ok provided they pass the golden rule – can they make decisions in the workshop on behalf of who they are representing? If they can’t then we need to get someone there who can.
Into the workshops, we first agree clear rules to ensure that everyone is there with the right purpose – to make decisions and it’s ‘speak now or forever hold your peace’.
The primary outcome we’re looking for from the workshops is a ‘Go / Go No’ decision. With the right people in the room we can quickly understand whether a viable plan and business case is in play and if not we can stop wasting people’s precious time and kick the project back for further assessment or the bin. To do this we work through the following fundamentals using ultra high-tech tools such as whiteboards and post-it notes.
- What does success look like for the project and how do we measure that?
- What are the project’s scope, objectives and outcomes?
- Who do we need to work with to get this done? – both stakeholders and other initiatives? What are the quality expectations of the stakeholders?
- What are the key risks of the project and how will they be managed?
- How will the project communicate with stakeholders and what change management activities are needed?
- What are the project’s tangible and non-tangible benefits? How will those benefits be delivered?
- What are the specific tasks that need to be completed? What is our best estimate of how long these tasks will take and what they will cost?
- Given the above… do we have a valid business case?
This fast, workshop based approach avoids the more traditional play of a Project Manager working around stakeholders in a fractured, drawn out process that takes many weeks just to get to that initial decision point. Agendas and office politics play out very easily in the traditional offline approach to project decision making. Using our peer workshop approach makes it much more difficult for people to curtail the progress of good initiatives or, worse, to promote the progress of bad ideas.
Assuming a ‘Go’ decision is made, the other outcome we want is a set of engaged stakeholders buying in to the project, believing from the outset that it’s a viable initiative and keen to be a part of it’s successful delivery. This is a natural by-product of the workshop approach. Our critical stakeholders work through the fundamentals listed above, have the opportunity for challenge as we go and don’t leave the room unless there is clear agreement that this initiative is the right thing to do and realistically achievable.
Expand
At this point we will have a good outline business case but we also would have identified areas that need some more substantial investigation or that needed to be added to the ‘parking lot’ during the workshops. Often there are PMO or similar processes to complete to get to formal agreement and budget allocation. We need to expand that outline business case – again as quickly as is feasible so we can get on with delivering business value.
Through the Outline workshops we will have planned out the ‘who, how and when’ of expanding the initial case to a complete set of Initiate deliverables. The key point to consider here is ‘fit for purpose’, we want to flesh out the deliverables from the Outline workshops but keep them as lightweight as they can be while meeting the needs of a successful project. And we want the right people – those stakeholders again – to be responsible for helping pulling it all together so we maintain engagement.
Again this should not be a PM beavering away in isolation to get this done, getting dragged in to multiple go-rounds of ‘document review hell’. At Luminate we challenge the time it takes to get this done. Fit for purpose, clear Initiate deliverables should take a few days to a few weeks to get together. None of the 2-3 months of bureaucratic nonsense we see too often.
We then take everyone through a quick review of the first ‘Go / No Go’ decision to check nothing has changed significantly from the Outline stage… If we are a ‘Go’ then we’ve got a solid plan, an engaged group of stakeholders and a keen project team ready to roll. It’s time to Deliver.
Apr 27, 2018
Got a project that’s out of control? If the project is red, you need to do something differently. It’s what you do next that counts!
Apr 19, 2018
Last week we looked at what was keeping you awake at night. Out of control projects with budget blow outs, scope creep, schedule over-run and a project manager that wasn’t able to provide you with the facts. You’ve been sitting in senior leadership meetings and you just know that your peers are losing patience. After all, they’ve a ton of pent up business demand waiting for you and your project to launch and get out of their way. You can’t really blame them. Their bonus is likely to be tied to the revenue lift or cost saving initiative that you’re stopping them achieving.
Thankfully, you’ve taken control and ownership of the situation and sent a clear message to the business by appointing an independent recovery manager. You’ve now got everyone’s full attention and support and it’s time to build recovery momentum. A quick fix is not going to save the day. Now you need to understand the extent of the trouble being faced.
What’s really been happening?
This is where facts become your friends. How bad you are really in the @#$% needs to be established … and quickly! How much are you over the approved budget and what is the estimate to complete the work? How are you tracking against the baseline schedule? Does it bear any resemblance to reality? And the really big one; will all the benefits declared in the business case be realised. The fact is that if any one of these is found to be significantly outside the pre-established tolerances, the project is red and requires a comprehensive and structured approach to recovery. Even more confronting, the recovery plan is likely to be very different to the original project plan. In fact the deliverables in the recovery plan may vary greatly from the original business case scope.
This requires the sponsor and project executive team to negotiate, agree and approve the changes ahead of executing the recovery process. That means concessions need to be made and inevitably someone will lose out on the benefits they’d banked on.
Similarly, agreement and acceptance is required from all parties that to properly analyse and fix the project requires a change in approach to delivery management. This means planning and implementation of realistic and pragmatic corrective actions and recovery processes; not just point solutions that paper over the cracks.
Establishing the facts
With the appointment of the recovery manager, the sponsor and executive team need to establish the recovery guidelines defining:
- Scope of the engagement
- Mandate and decision making authority
- Roles and responsibilities of all parties involved
- Overall recovery plan approach including
- Decision gateways
- Reporting and communication
- Success or acceptance criteria
You’ve now got an anchor point for the recovery. It’s time to take the plunge. There’s no way around it. A review, an evaluation, a fitness test … is an audit by another name. Nobody likes them; but they are the vital next step in establishing the facts upon which a recovery plan will be formulated.
It’s important to understand history because that helps determine root cause. But you don’t have a time machine and relentlessly searching for and appointing blame is not productive. You can only change what’s ahead of you and that must steadfastly be the focus of the recovery manager.
The first step in gathering data is an anonymous survey of stakeholders and delivery team members to assess where the major problems within the problem project lie. This serves two measures. Firstly it opens up the lines of communication with the wider team. Secondly, the output from this survey is used to tailor interview questions and guidelines for 1:1 interviews with the stakeholders and key delivery team members.
Two-way communication and trust
The interview process ensures two-way communication is established early between the recovery manager and the extended project team to build trust and confidence.
Typically the project team in a failing project is feeling ignored. Without people, there isn’t a project. What they do or don’t do determines the success or otherwise of the project. A troubled project with talented, motivated people is far more likely to recover and succeed than one with a weak team.
The three simple questions below demonstrate to the interviewees that their opinion is valued. When given an opportunity to open up the information flows.
- What are the issues for the project?
- What would you do to fix it?
- What do you expect of the recovery manager?
Root causes of failure
Whilst there are myriad reasons for project failure these can typically be aggregated into three problem areas; Stakeholders, Delivery Team and Process. Furthermore, the specific root cause of the problems identified within these three areas is nearly always related to poor communication, poor project definition and scope creep.
Next time we’ll dig deeper into the most common root causes and how to address these to avoid repeating the problem during the recovery execution.
