Categories: Project Management
A project manager asked me this week whether I was aware of any studies which could be used to justify the assignment of a "real" project manager to manage a project as opposed to having this function performed by someone else within a team. While I'm sure PMI and other project management associations have researched this thoroughly, I felt this would be a good topic for an article.
In some companies, such justification is not needed on a project by project basis. Organization policies or standards might require that projects exceeding a given estimated total cost or those that are over a certain level of complexity must have a project manager assigned. However even in these companies if perceptions fester that the role isn't adding value, standards owners may be pressured to raise the thresholds at which project managers are required.
But in those companies where such standards do not exist, the battle might need to be fought at an individual project level. Convincing the funding authorities for these projects that a project manager is needed could be done in a couple of ways.
A fear-based approach might be used. This requires creating a sense of urgency by highlighting data from project failures or by communicating the personal risks to the stakeholder if something were to go wrong as a result of not having a project manager assigned. A decision tree could be used to compare the expected cost outcomes of both sides of the decision. While this might seem to be a reasonable approach, unless you are dealing with a particularly risk averse stakeholder, optimism bias is likely to cause the sponsor to ignore your arguments.
A different approach might focus on promoting the upsides of using a project manager. While this approach will be much harder to justify using financial projections, it doesn't put the sponsor in the uncomfortable position of having to imagine their pet project failing and the emphasis is on showing the incremental benefits which they might achieve by having a project manager. Increased outcome predictability, improved communications, better focus by other team members on delivery, higher levels of stakeholder and team member engagement are just some examples of the advantages which could be communicated.
Regardless of a company's level of organizational project management maturity, ensuring that the costs incurred by a project manager are providing some value in return is important otherwise it shouldn't be a surprise if sponsors push back on the need to assign one.
Some of our greatest achievements are realized through the willingness of people to strive for what seems to be impossible. Without this will, we likely would not have reached the moon or split the atom. But constraints are one of the most important elements of a project. They are the gatekeepers on what is and is not possible.
So what happens when decision makers insist on trying to deliver fixed scope with unrealistically low timelines and resources? A common outcome is that something gives. Scope is only partially delivered, quality suffers or schedule and cost baselines are exceeded. What’s interesting is that when such project overruns are analyzed, many times we see that the final actuals are in fact fairly close to what the initial estimates were.
Is this a self-fulfilling prophecy on the part of team members?
Sometimes it can be!
If the team is not convinced that their objective is achievable, there’s a good chance that they will fail.
But in many instances, it is caused by the analogy I’ve used in this article’s title – like a spring, a project can be compressed. But after a certain point, sufficient linear restoring force has built up that the spring will return (usually violently!) to its original size.
But let’s not ignore the reality that a project needs constraints. Without these, it consumes resources indefinitely without delivering proportional value. Like a spring, you can stretch a project to a defined extent, but once elastic potential energy has exceeded the spring’s design, it will either snap or be permanently deformed.
As project managers, one of our responsibilities is to facilitate appropriate decision making. If your attempts to convey the impossibility of a requested project scenario are falling on deaf ears, leverage the power of analogy, and illustrate your concerns by using a toy spring.
(Note: I stretched this metaphoric spring in January 2012 on kbondale.wordpress.com)
How effective are your agile ceremonies?
We hope that by conducting effective ceremonies we will achieve the agile trinity of improved value delivery, better quality and more fun.
But these objectives might be reached via multiple paths so we might not be able to prove causality between our ceremonies and those objectives.
We could ask our team members to tell us whether they see the value in the ceremonies and their perceptions are certainly important but is that enough? Can we identify measures which we could directly attribute to specific ceremonies so that we know if they are generating sufficient value?
Each agile framework provides its own ceremonies but given that Scrum is still the most commonly referenced one, let's focus on that framework's events.
The Scrum Guide calls sprints the heart of Scrum as these time boxes set the cadence for all other events. But to know if the Scrum heart is healthy we could track achievement of goals and value delivered sprint-over-sprint.
Sprint planning should answer the "what" and "how" of delivery for an upcoming sprint. Measuring its duration, quantifying the variation between what was expected to be delivered and what was actually delivered, and confirming whether the team is working at a sustainable pace might help assess the ceremony's effectiveness.
The daily scrum helps the team align themselves towards the accomplishment of sprint goals and to collaborate better. It should also reduce bad surprises and the need for traditional status meetings. To see if it is adding value, we could check how many work items are completed and measure how many unanticipated impediments are encountered each day.
The sprint review provides an opportunity to inspect what was accomplished and adapt the backlog accordingly. We can measure how many new requirements and course corrections emerged from the discussions. We could also conduct regular surveys with key participating stakeholders to gauge their satisfaction with the product and with the team.
Finally we come to the sprint retrospective. To gauge whether this ceremony is more than just a frequent "lessons learned" session, we could track the ratio of improvement ideas generated compared with how many were actually executed and provided expected benefits.
Agile ceremonies should add value. If not, we are just adopting the form of agility with none of its substance.
Steve Kay, a Program Manager interviewed in the Closing Credit article of the August 2012 issue of PM Network made an interesting change on his mega-project – he altered the typical 5×5 risk matrix (e.g. very high – very low) to a 4×4 one to remove the “sitting on the fence” option for those participating in the qualitative risk analysis process.
This prompted me to check the risk registers for a few of the historical projects I’d been involved with and I noticed that when there is a three or five rating scale for probability and impact, the medium selection is picked much more often than one of the other choices. This should not be a surprise since we can draw a reasonable conclusion that probability and impact values follow a normal distribution for projects with an average level of risk.
My concern is that the frequent selection of this rating relates more to indecisiveness or lethargy than to statistics.
The former cause might be tied to the common behavior in some organizations of people being unwilling to take a stand. With a three point rating scale, providing a low severity for a risk which you had previously identified might incur the wrath of those minimalists who want the focus purely to be on critical threats or opportunities. Doing the same for someone else’s risk event might put you at loggerheads with them as they might perceive a very different severity for their risk. On the other end of the scale, assessing a risk event as high might brand you as a “Chicken Little”.
Such behavior might occur if risk analysis participants are lacking knowledge on what the different ratings imply and how to score risks, but more likely it is caused by participants that are uninterested in the process. I believe that most staff are so focused on their day-to-day operational and project work and the “real” issues that plague them that they wish to minimize their effort spent on risk management which they perceive as being at best, an academic practice.
The recommendation in the PM Network article is a simple way to address the inappropriate use of medium ratings as it forces participants to pick ratings that will be either above or below the point of indecision. This method could be enhanced by one or more of the following practices:
Yoda said “Do or do not, there is no try” – medium might just be the “try” of risk management!
(Note: this high value article was originally published in August 2012 on kbondale.wordpress.com)
After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.
The Scrum Guide doesn't specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.
Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.
Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?
Just as with providing constructive feedback, we shouldn't wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.
A recent Washington Post article described how kindness can be contagious.
Anyone who has participated in or initiated a "pay it forward" chain would likely agree with the article's author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.