Long-time readers of my blog will know that I support the concept and principles of objective project prioritization. However I am pragmatic and recognize that a significant percentage of the organizations who aspire to having objective rankings of their active and pipeline projects can’t get there overnight, and even as their practices mature, they still must successfully deliver multiple parallel projects with constrained skills and capacity.
If this sounds like your organization, what can be done to meet commitments while not ignoring the practice improvements required to achieve a more manageable active project portfolio?
Juggling multiple balls might seem like an impossible feat to an untrained novice but just as jugglers develop techniques and practices to do this, it is possible for organizations to improve their ability to manage multiple concurrent must-do projects.
However, even expert jugglers eventually tire, and if the volume of concurrent work doesn’t subside to more manageable levels in time, inevitably one or more critical project “balls” will drop along with a side order of skilled staff attrition.
(Note: this article was originally published in August 2013 on kbondale.wordpress.com)
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?
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.
Recently I wrote an article about the potential for a Scrum Master to take on additional roles. While I was teaching a class this week, one of my learners voiced a concern about Scrum Masters who didn't possess deep technical knowledge of the product solution. He felt that without this expertise a Scrum Master would run into difficulties in building credibility with the Development Team. He also believed that a Scrum Master lacking this knowledge might not know enough to ask the right questions when trying to understand specific technical risks or impediments and hence wouldn't be effective in clearing hurdles from the team's path.
Having been posed similar questions in the past with regards to project managers, I believe the answer is consistent for both roles. Some technical knowledge is necessary, but given a choice between a technically savvy Scrum Master who isn't an effective servant-leader and one who has some technical competency but does a much better job of improving interactions within and outside of the team to enhance value delivery, I'll always pick the latter.
To keep myself honest, I decided to double-check my views against The Scrum Guide™. The only activity listed for the Scrum Master role which could be interpreted as requiring technical competency is listed in the Scrum Master's service to the Development Team: "Helping the Development Team to create high-value products". I take this as meaning that a Scrum Master has sufficient competency to encourage technical excellence but isn't necessarily challenging specific technical decisions or contributing directly to solution design or development.
A few years back I'd written an article covering the pros and cons of a project manager being a technical subject matter expert. The same risks apply to a Scrum Master such as the potential for the Scrum Master making assumptions based on their past hands-on experience or the likelihood of their butting heads with team members when they disagree on specific technical matters.
As with all Scrum Team members, I would encourage Scrum Masters to become generalizing specialists and if they possess the capability and capacity to help the team achieve sprint goals, they should, but making this a default expectation of the role suggests that the supporting organization is not able to form a "whole" Development Team. Quoting The Scrum Guide™ again, "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment".
Servant-leadership is a lifelong journey of self-discovery and personal development. Let's not divert focus from that critical path by requiring Scrum Masters to also develop deep technical expertise.
I’ve frequently said that project management is about bringing predictability to uncertainty and while a lot of my writing focuses on managing the impacts of uncertainty through effective risk management, estimation is another area where uncertainty needs to be addressed.
If you are fortunate enough to be managing projects where sufficient historical data exists to account for nearly all sources of variation then I envy you.
For the rest of us, here are some estimation principles which should be applicable regardless of the project’s domain or specific context.
Improving estimation is not a silver bullet to slay all sources of project schedule or cost variation but elevating project management capability is about evolution, not revolution!
(Note: this article was originally accurately estimated and risk reduced in July 2014 on kbondale.wordpress.com)
Risk Management is not an island!
Categories: Risk Management
Although the PMBOK Guide has individual chapters covering key project management knowledge areas, it also highlights the importance in an approach which integrates these knowledge areas in a pragmatic, tailored manner to fit the needs of a specific project taking into consideration organizational and team culture.
One of the most common examples of poor integration across the knowledge areas occurs with risk management. Risk management needs be tied at the hip with other project management practices, but too often it is as isolated as a porcupine at a balloon convention.
What do I mean by this?
Risk is the embodiment of the uncertainty which is inherent in the DNA of projects. Until all agreed-to scope has been delivered and accepted, risk does not disappear so why do we not connect the dots by referencing it in other key project management artifacts?
It starts with the charter – while expressing the desired outcomes and drivers for the project, there should also be coverage of the key sources of risk which could impede the realization of these outcomes.
It continues with other core planning artifacts such as stakeholder analysis documents and organization change management (OCM) plans – risks from the register should be referenced in specific stakeholder management plans and should form part of the rationale supporting your OCM strategy.
Risk drives variation in outcomes and hence the cost and time contingencies reflected in cost estimates and schedules should link back to specific risks in the register. Risk responses for high severity risks should show up as line items in the schedule and should have been baked into your baseline budget.
Project changes should directly tie back to items in the risk register – closed and open risks. Some project changes may eliminate certain risks – this is why one of the ways to implement the risk avoidance response is to reduce scope. Other changes might introduce a whole new set of risks. A well maintained risk register should be able to provide a forensic trail of project change.
Issue logs should also show evidence of traceability to risks – when known unknowns are realized as issues, linking those back to the originally identified risks provides the opportunity to assess whether there is a future likelihood of occurrence and can provide valuable input into post-project assessment of risk management practice effectiveness.
All decisions need to consider risk – analysis leading up to a decision should consider the risks associated with each option, and risk register updates should capture the uncertainties tied to the final decision.
Risk management is like quality – if you tack it on, the value derived is less than if it gets baked in as an intrinsic part of your overall project management approach.
(Note: this risk-free article was originally published on kbondale.wordpress.com in September 2014)