Project Management

Articles related to doing projects right

Justify yourself!

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.

Advertisements
Categories: Project Management | Tags: , | 1 Comment

Project lessons from playing pool

A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.

I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.

Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?

  1. Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
  2. No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
  3. Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
  4. Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won’t work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
  5. It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent’s balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.

Finally, “Take care of your cue ball, and it will take care of you“. Support and lead your team and they will help your project succeed.

 

 

 

Categories: Project Management | Tags: , , , | 1 Comment

How many hats should a Scrum Master wear?

I’ve run into a few situations recently where Scrum Masters (SMs) are performing multiple roles and while they might have the capacity to do so, on any moderate sized initiative, it might be difficult for them to fulfill all the responsibilities of the SM role.

Some people may challenge this by stating that the SM needs capacity for daily standups, sprint planning, sprint reviews & retrospectives, but that should still leave them plenty of time to take on another role.

This perception is incorrect.

Agile ceremonies represent just the tip of the iceberg for an SM. As the intro to the SM role in The Scrum Guide states: “The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.” Notice the use of the word “everyone” instead of “the Development Team”. Surrounding any project or release are many stakeholders who the SM needs to work with to ensure that their interactions with the Development Team are in alignment with Scrum values. And as any good Project Manager will tell you, effective stakeholder management consumes a lot of time! Removing impediments from the team’s path will also take significant effort.

If the company does not have separate agile coaches to work on elevating organizational capabilities, the SM will likely spend effort on activities such as coaching executives, training functional managers and collaborating with their fellow SMs to identify patterns.

But let’s say we have agile coaches and there are minimal stakeholders for the SM to work with. Couldn’t an SM play another role?

Even if capacity permits, I’d still recommend avoiding either of these roles:

  • Product Owner: Even if an SM has sufficient product domain knowledge, an effective PO has to spend a fair bit of their time interacting with all the stakeholders who have needs and wants related to the product and the effort required to distill these requirements into a clean product backlog is significant. There is also a potential conflict of interest by having the “what” and the “how” intermingled.
  • Technical Lead: I know that a true agile team is “flat”, but for organizations going through their transformation journey, until quality development practices have been institutionalized and the shift from specialists to generalizing specialists is well underway there will be a need for senior technical contributors to review the work of more junior team members, mentor them and make key solution decisions. It might be difficult for one person to balance the servant-leadership and coaching stances of an SM with the more directive nature of a technical lead. When an SM is providing guidance to a team member, will that team member know which hat the SM is wearing?

Focus is one of Scrum’s five values. An SM playing multiple roles may not be providing their team with a good example of this value in action.

Categories: Agile, Project Management | Tags: , , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: