Apr 13, 2018
Let’s face it. How many projects have you been involved with that were planned and executed to perfection? How many have been delivered on time, on budget and with scope and requirements fully met? And how many times did you achieve all this without any conflict between stakeholders, the core delivery team and vendors? I bet the answer is bugger all.
Often you’re faced with projects that are out of control – budget blow outs, scope creep, schedule over-run and your project manager’s unable to provide you with the facts. You’ve lost confidence in your delivery team. And worse still, your peers are losing confidence in you. Your credibility is on the line. You’re fighting fires. And you’ve no time to do your day-job. The project is red. You need to do something differently. It’s what you do next that counts.
‘’In project rescue, admitting the problem is often the hardest part, but it is the necessary first step to recovery.” – Rick Freedman – Consulting Strategies Inc
You can’t do it yourself. You’re already knee deep in the weeds and the delivery team are getting pissed off with your micro-management. And they’re burned-out from your repeated requests to work nights and weekends. It’s no good asking the incumbent PM to lead the recovery either … remember they couldn’t tell you how you got in this position so they won’t have the foggiest idea how to get out!
You need to restore visibility, control and confidence to your stakeholders. It’s time for a radical intervention. The single most valuable action that you as project sponsor can take is to approve funding to bring in a recovery specialist. This sends a clear message to the project team and the wider business that correction of the problem is being owned and taken seriously.
Selection of the right recovery manager is critical to the likelihood of recovery plan success. The executive team needs to choose someone with no affiliation to the project. Objectivity is key. The ideal recovery manager is an independent, battle-hardened delivery specialist with recovery experience and a strong technical background.
Engaging an independent third party as a recovery manager has a number of advantages:
- Objectivity – a third party provides an objective view with no pre-conceived ideas, perceptions or opinions. They defuse emotion with facts and are clinical in their implementation of fact based corrective actions to address the root causes of problems.
- Management style – a new management style is often the catalyst to energise a fatigued delivery team and to restore control and confidence to stakeholders.
- Experience – an experienced recovery manager brings ‘war stories’ from other large scale project recoveries and instils an unwavering belief in the delivery team that ‘we can do this’. They know how to bring a team on the delivery journey and they understand what is required to get your project over the line; meaning you can get on with your day job
- Expertise – you need pragmatists … not agilists. A seasoned third party brings multi-discipline capability and experience and is delivery methodology agnostic.
- Abstraction – this is classic ‘good cop/bad cop’. A third party will objectively recommend people changes and/or scope reduction in order to stabilise the project. Meanwhile you as sponsor avoid animosity from the incumbent delivery team stakeholders.
The sponsor and the exec have taken the first and most important step. They’ve accepted that they have a problem and have taken action to resolve it. A recovery manager has been appointed and the rules of engagement and criteria for success have been defined. You’ve now got everyone’s full attention and support. Now it’s time to find out the facts and build a recovery plan.
Next week, we’ll look at how you go about identifying the root cause of the problems and how to plan and negotiate a successful recovery.
Apr 6, 2018
One of the key technology trends over the last decade or three… showing our age there… has been the broadening use of ‘Agile’ software development techniques. If you didn’t know that then you’ve been living in some sort of technology free cave for quite a while.
So much has been written about Agile we weren’t sure where to start. So as always we consulted with the oracle… Dilbert.
Unfortunately what we see all too often is either partially successful or completely failed implementations, often because they had too much focus on Agile adoption being a process change rather than cultural change.
The real shame is that a well-constructed Agile delivery group really does work. And when you see it working it is quite a beautiful thing. Teams working under an effective Agile method are able to produce high quality software targeted at areas of maximum business value, with flexibility built in that deliver without destroying the project team along the way.
So what are some of the common myths or mistakes that we’ve seen across the many Agile implementations we’ve been party too?
1. A little bit of Agile is better than none
And is better than smelly old Waterfall.
A well thought out Waterfall based methodology that is widely understood, regularly reviewed and continuously improved will still out-perform any half-baked Agile implementation. Methodologies do not make great projects, people do that. But poorly implemented methodologies are a sure fire way to lock in project failure.
It’s easy to throw in a few stand up meetings and a retrospective or two but that doesn’t make you Agile. Any good project method will look at basics like project communications and regular review/refine cycles, that’s not some revolutionary thinking that Agile has brought to the party.
And as the saying goes you can’t be half pregnant… so if the drivers exist to consider an Agile implementation then it needs to be approached with 100% commitment. The implementation of an Agile method is a significant change management exercise and needs to be planned and executed with the highest degree of care and not nibbled at out of interest.
2. Iterative = Agile
Following on from the above point we also see many Agile teams working only in an iterative way. This ‘AgileFall’ approach is often the result of a curtailed or misinformed attempt at adopting Agile which has withered away over time until only some of the basic mechanics of Agile are being followed. Unsurprisingly these situations don’t produce great results, at best they may improve on some elements of software delivery but often results are no improvement at all. A common complaint we’ve heard from business stakeholders is “they spent all that time on adopting Agile and now they just go slower”.
Good Agile projects are iterative as well as many other things. But often we see projects with locked in scope not just for a sprint or iteration but for several iterations ahead. This is symptomatic of an Agile tech team dealing with business stakeholders unaware of their role in the Agile project. In reality the result is a series of Waterfall projects, little improvement in the ability to handle change, little tolerance by the business to ‘build it then build it better’ and overall outcomes marginally improved if you’re lucky.
When you have a Product Owner come to the team mid-sprint, excited about a change they want to introduce right now to already delivered software and keen to agree what to remove from the sprint to accommodate the change then you have something that is a long way past just iterative.
3. Agile adoption is best driven by the technology group
In our experience successful implementations of Agile methods need engagement organisation wide. What does an effective Agile team look like? Well it’s a long way from just a bunch of tech gurus with a burn down chart. It starts from the business with the role of Product Owner and must have buy in across the organisation to have any chance of success.
Remember the Agile manifesto… it says that we should value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Individuals, their interactions, how they collaborate and respond to change are all people centric things that require a focus on cultural change. Unsurprisingly we see Agile implementations driven by technology groups become too focused on the adoption of tools and related development processes with insufficient focus on the cultural changes that are critical to successful Agile adoption.
4. Agile means no design and no documentation
Here’s the oracle again…
Mar 30, 2018
All of the more notable advances in project delivery methods in the last 10 years have had a particular focus on people more than process. Not people in place of process but certainly people first.
For example the first of the four principles that make up the Manifesto for Agile Software Development values “individuals and interactions over processes and tools”.
It’s stating the obvious but delivering good projects is first and foremost a people endeavour. Without the right people connecting as an effective team your project faces an uphill battle to succeed. But what are the elements of people management that those accountable for successful projects need to ensure is on their radar?
The three ‘c’s – capacity, capability and chemistry
To have an effective team on any technology project – or any project for that matter – requires that:
Individual team members have sufficient time and the right skills to deliver what is required of them, and that those individuals are able to function well together to produce an outcome greater than the sum of their individual parts. They need capacity, capability and chemistry.
Capacity is important bit it can’t be the only focus
Unfortunately what is regularly evident from project outcomes is that senior execs and SteerCo’s are focused only on the capacity part of the people equation with much less regard for capability and chemistry. This may be because it’s easier to understand, measure and adjust capacity given it is largely quantitative. There is a direct linkage between capacity and project costs – the traditional first focus of any SteerCo. The ‘Time, Cost, Quality’ triangle has been understood for over 50 years and it’s obvious that not having sufficient allocation of resources has a direct impact on project outcomes.
The management of capacity remains a critical element of generating project success but it needs to be considered not in isolation but also against the other two key elements.
Capability and the scale effect of highly functioning people.
What we know about capability in technology projects is that experienced, capable and motivated project members have a massive positive impact on output and outcomes. The difference between motivated senior team members and those still learning on the job is measured in multiples not in small percentages.
It’s not possible to replace a good senior developer with two junior developers, the scale quantum is more likely to be over 400%. And in many situations this type of switch just doesn’t work, you need that experience to get the job done, an army of juniors just won’t get you where you need to be.
Having a lack of capability in key positions, particularly the leadership roles of a project team, also has a knock on effect across the project. The impact on chemistry and motivation across the team is high when it’s obvious one of the leaders is out of their depth.
Capability can be a tricky subject for execs and SteerCo’s to manage, in particular when dealing with employees rather than contractors. Often allocation of staff to projects is driven as much by availability as it is by suitability to the specific role. And it’s common to see staff being deployed outside of their core skill set or to be given opportunities as part of professional development.
A good SteerCo will ask whether there are other opportunities in the organisation for that professional development to occur. “Does it have to be on my project?” is never a bad question to ask.
To balance this with the realities of organisational resourcing SteerCos and PMOs should focus on the three most important roles for a given project. Sit down at the start of the project and identify what these three roles are, then apply a high degree of scrutiny to filling them with performance focused, capable individuals. If that means looking externally to ensure these roles are filled appropriately then that should be what happens. As an example, on most software development projects these key leadership roles would usually be the PM, Senior BA and Solution Architect or Tech Lead.
Filling the other roles in the project team can then receive more leeway with regards capability if necessary (although that shouldn’t be allowed to compromise chemistry as detailed below).
And don’t stop once the project is underway. Continue to regularly assess capability – projects change and the needs of these key roles may change too. Ensure you are able to assess whether capability gaps have developed through formal and informal reviews. Consider the use of things like anonymous team surveys if it’s difficult to gauge the fit of key individuals.
If evidence of capability gaps comes to light then you must have the courage to act. Very few projects are completed with the team that started them, personnel change can be a positive or negative thing. Execs and SteerCo’s should get on the front foot and manage that change to ensure the impacts are positive.
By understanding the scale impact of capable and motivated individuals and ensuring the three key leadership roles are filled with proven performers the Steer Co will have ensure the project has a good chance of success.
Chemistry and the power of Effective teams
The other element of people and projects that has traditionally been difficult to get a handle on is the overall chemistry of the team. “There’s nought as queer as folk” and getting people with different perspectives and backgrounds to pull together as an effective team is definitely an artform.
Throughout the lifecycle of any project time pressures, stresses and differences of opinion will always present the opportunity for conflict. An effective team will manage that conflict and channel the resulting outcomes in a positive way. But if there are personality difficulties or unmanaged bad behaviours then these pressure points will lead to significantly negative impacts on the team and the project.
The other challenge with team chemistry is that a lot can happen below the waterline. People will often put up with bad behaviour or negative conflicts without escalating to those who can act. If a SteerCo is operating on a passive, raised-exceptions basis then there can be significant impacts to chemistry without awareness that these problems exist. Symptoms like slipped timeframes, poor quality or team turnover may be indicative of a root cause issue with chemistry. But it will often be difficult for the SteerCo to work back from these symptoms to the real underlying issues.
Those responsible for the successful delivery of projects need to acknowledge the risk of individual conflicts and plan for how they can measure the intangible elements of an effective team.
Start by getting items on the risk register that cover team chemistry with mitigation plans focused on measurement over the duration of the project. There are myriad low cost, effective tools that can be used to take the regular temperature of the project and identify any significant changes over time. Online survey tools, project collaboration tools and others offer easy ways to blend this measurement into the regular rhythm of the project. It might be as simple as including checks in retrospectives or similar reviews on how people are feeling about the success of the project.
When it becomes evident that chemistry is an issue the Exec team or SteerCo must act. Obviously the best approach will be to address the causes of conflict directly and attempt to influence people to change. Often the use of facilitation from those external to the project can bring the best results in this regard.
Most critically if these efforts are unsuccessful then you must have the courage to act. If people aren’t able to change their behaviours then you must be prepare to change the people on the team.
To summarise…
How do those accountable for the successful delivery of projects ensure that their team is set up to succeed?
- Don’t forget about capacity. Starting with the easier element to control, ensure when you allocate people to the project that they have sufficient time to deliver what is expected of them individually and collectively and that those allocations are clearly understood by all relevant stakeholders.
- Undertake an up-front assessment of where capability will have the biggest impact -positive or negative – on your project. From that assessment identify the three key roles for the project. Then ensure those roles are filled by the right people without compromise.
- Instigate ongoing assessment of capacity and capability to ensure that all roles remain well filled for the duration of the project. Act quickly when gaps become evident.
- On project start up get project team chemistry on the risk register and agree on how you can measure it as you go. Use simple surveys through to people focused project reviews to monitor the temperature of the project team.
- Take any changes in that temperature seriously. If the cause can be traced to individual personality conflicts then act. A destructive personality or relationship in the team can’t be tolerated, either resolve or remove.
Sponsors and SteerCo’s need to recognise the importance of capability and chemistry in their project teams and bake that recognition into project start up. They then need the ability to monitor and measure the impacts of gaps in capability and a lack of project team chemistry. And most importantly they need the courage to act on any concerns they have around these risks. Be brave, especially around key project roles, and remember if you can’t change the people … change the people.
