Easy in theory, difficult in practice

Breaking projects into time boxes known as sprints or iterations is often associated with agile delivery approaches but can also be used to deliver on detailed requirements for an overall project’s scope following the (infamous) approach commonly termed “Water-scrum-fall”.

The benefit of this approach is that it helps to focus a delivery team on a small, achievable set of work items, providing stakeholders with frequent opportunities to provide feedback on completed work items while increasing the transparency and objectivity of progress reporting.

Agile delivery approaches encourage prioritization of the work backlog and this can also be a good practice when using sprints with traditional projects. But this prioritization might not be sufficient to generate a desirable level of energy and focus from the team, so why not define specific goals as one of the team’s standing agenda items for a sprint planning ceremony?

Sprint goals can help by:

• Providing a measure of progress over and above completion of individual work items from the backlog. Meaningful sprint goals are truly milestones worth celebrating!
• Giving voice to accomplishments that transcend scope delivery. For example, completing all work items for the sprint with zero defects or meeting sprint commitments without requiring any overtime from team members are both achievements worth celebrating.
• Helping to focus the delivery team and key stakeholders on meeting a shared objective. This can encourage team self-discipline as they can use alignment with the sprint goal as a key determinant for whether a new work item proposed by a stakeholder or team member is worth adding to the sprint backlog.

Sprint goals should not be dictated, rather they should emerge out of the collective gestalt of the team and are a good pulse check for whether the team is aligned to the overall project vision.

When defining goals, the usual SMART (Specific, Measurable, Achievable, Relevant and Time-bound) acronym can be used to test and refine them.

At the end of a sprint, the showcase or demo should include a presentation of the goals and whether or not they were accomplished, and the team’s retrospective ceremony should include a review of the goals including the identification of ideas for improving goals for future sprints.

As Albert Einstein said “If you want to live a happy life, tie it to a goal, not to people or things.”

(Note: GOAAAAAAAAAAAAAAAAAAAAAAAAL! This article was originally published in April 2017 on my personal blog, kbondale.wordpress.com)

Through education or experience most of us learn early in our project management careers about the dangers of using percentage complete for any activity where the work completed cannot be reliably measured. This is unfortunately the case for most knowledge-based work.

While a contractor can examine a wall being built and verify what percent of the work is complete based on how much of the wall has been finished, a development lead looking at the source code for a given function will be unable to come up with more than an educated guess as to what the true status of developing that function is. That is why we are encouraged to ask objective questions such as "How many hours of work is remaining?" or better yet, to utilize conservative reporting methods such as 0% and 100% or (for those in the agile delivery space) Not Done and Done Done.

So why wouldn't this also apply to resource availability?

Unless you are benefiting from either a project-oriented or a long lived team, chances are your team members will not be dedicated to your project.

I'm not referring to the normally expected non-project activities that everyone incurs such as department meetings, HR activities and so on. While there is an ebb and flow to those, there is usually a combination of historical data (e.g. at least 20% of the month before fiscal year end has been proven to be spent on annual performance review activities) and personal plans such as team vacation calendars to provide confidence about those estimates.

What concerns me is when a people manager gives me a percentage availability. "I can't provide Bob full-time, but I can give him to you for 50%". This occurs so frequently that we rarely challenge it unless we are sure that a staffing shortfall will critically impact our project's objectives.

But what does 50% of Bob really mean?

• Is it 3.5-4 hours per day, every day for the duration of the project?
• Is it Mondays, Tuesdays & half of Wednesdays for the duration of the project?
• Is it Mondays, Tuesdays one week and Wednesdays, Thursdays & Fridays the next week?
• Is it 75% time for half the duration of my project and 25% for the second half of the project?
• Or (and this is the most likely case) is it that at the end of the project, if I divided Bob's actual hours spent working on my project by the potential hours he might have worked if he had been allocated full time, it will be close to 50%?

And what will be the impact to your timelines and other project success criteria if you made the wrong assumption?

So the next time someone gives you a percentage availability commitment for a team member, ask a few questions to really understand how much time that person will be dedicating to your project and when.

If your body temperature is average but half of you is in a freezer and the other half is in an oven you aren't likely to be too happy!

We all recognize the criticality of effective project sponsorship. The selection of the right individual for the role and an onboarding process to help them properly fulfill their responsibilities can increase the odds of project success.  Sponsorship is a key component of project governance.

Project governance does not end there.

There are always going to be project decisions which a sponsor won’t be able to make on their own. A common example of this is a funding request which exceeds the financial authority of the sponsor. Sponsors may also be unable to unilaterally make decisions or remove hurdles which impact functional areas outside of their jurisdiction.

What does overall governance effectiveness & efficiency even mean?

A well designed, properly implemented governance framework ensures that project decisions are made in accordance with organizational policy and that they fit within the organization’s risk appetite. It ensures that these decisions are made with minimal wasted time and effort such that project flow is not impeded. Good governance is also there to act as a safety net for issue resolution such that hurdles which impede a project and which can’t be resolved at the team level are dealt with in a timely fashion such that project impacts are minimized.

So how can you assess if your project’s overall governance process is both effective and efficient? How do you know that you’ve found the sweet spot between too much process and anarchy?

Here are some symptoms of governance gangrene which could help you make some immediate improvements or could at least help you to identify lessons which could be applied to future projects.

Frequent reversal of decisions. While this is sometimes caused by excessive multitasking or making decisions prematurely, analysis of reversed decisions may reveal insufficient engagement of the right stakeholders when decisions are first made. Thorough stakeholder analysis and consideration of broadening the governance safety net may be one way to reduce the likelihood of this.

Excessive effort spent on administration or documentation supporting decision making. If more effort is spent on supporting the decision making process than coming up with the decision recommendation itself, that’s often a sign of a bloated, wasteful governance process. Process analysis to determine non-value add steps could help to lean governance out.

Decisions or issue resolutions are chronically late with measurable impacts to the project. If death-by-committee is causing decisions to be made long after the time when they should have been made, an assessment should be conducted to determine if the processes are too complex and can be shortened and if not, is there a way to move up the timing for when decision requests are submitted.

Governance committees never evolve beyond the storming phase. It’s a good practice to establish a steering committee or advisory group on large, complex, cross-functional projects, but if there is no one supporting them through Tuckman’s stage of team development, your project could end up falling victim to long standing executive personality clashes or organizational turf wars. A strong sponsor can help in such cases by acting as an informal coach to the committee.

Blessed with a good sponsor but cursed with ineffective or inefficient project governance?

Diagnose it, or you might be humming “One is the loneliest number that you’ll ever do.”

(Note: this article was approved through lean governance and published in January 2015 on my personal blog, kbondale.wordpress.com)

For organizations lacking standard practices in project portfolio and project management, risk management might seem like an unnecessary use of resources.  I’ve even heard some executives say that with insufficient resources to deliver the expected scope on all of their “critical” projects, how can they afford to have project teams “waste” effort on risk management activities.

For those of us that have come through the PM “school of hard knocks”, such statements might appear myopic if not downright idiotic.  However, this leadership perception of low value in this knowledge area often stems from poor implementation of risk management practices – an article I wrote a few years back highlights some of these issues.  Buried within that article was an analogy that might help you convince your executives of the benefits that value-based risk management can offer.

Ask the nay-saying executive whether they have purchased house insurance.

If they have a mortgage on your property, their lender will probably insist on coverage for at least the value of their loan.  However, once a mortgage is paid off, the home owner could elect to avoid insuring their house, but most people would likely still maintain this insurance over the duration of their home ownership.  If you ask the executive why they do this, they’d likely offer some variant on the following rationale: “to protect my investment from the unknown”.

Probing deeper, if you ask the same executive how much they spend on home insurance each year, and you multiply that by twenty years, you would likely come to a figure that is at least 2% of the original purchase price of the home.  Insurance is just an example of the transfer risk response approach.  If we added all the costs we incur to mitigate home risks, the 2% estimate would likely be significantly higher.

So, after having led the executive through this analogy, leave them with the question “You agree that it is important to insure your home against the unknown, so why not apply the same approach to the projects you are sponsoring – surely they are as important to the organization as your home is to you?”.

Investing in the right amount of risk management “insurance” can protect your project from the catastrophic costs of fire-fighting.

(Note: this article was underwritten by me in February 2011 on my personal blog, kbondale.wordpress.com)

The fourth and final statement in the Manifesto for Agile Software Development states that we should value responding to change over following a plan.

The purpose behind this preference is to ensure that while a plan might be created to guide team efforts, there should be openness from the team, product owner and key stakeholders to encourage and incorporate changes which will deliver greater business value for our customers.

But as with everything, moderation is key as on more than one occasion I have seen team members experiencing virtual whiplash from a high frequency of significant requirement changes.

Teams will become more change resilient as they mature but there is a natural limit to the volume of changes that any team can absorb.

Think of Morpheus fighting Agent Smith in The Matrix. Morpheus is an accomplished martial artist and has full confidence in his abilities to hold his own, but at a particular point in their fight the frequency of Agent Smith's punches is simply too fast for Morpheus to block.

The team remains busy completing work items but it feels like a random walk to nowhere and morale will suffer as they see that they are regularly taking one step forward and two or more steps back.

Even though the eleventh principle in the Manifesto states that the best architectures, requirements, and designs emerge from self-organizing teams, it is impossible to create a quality architecture or design which is capable of incorporating frequent, major shifts in direction. Frequent major changes will also encourage short term thinking by the team which could cause an increase in the level of technical debt.

This is why it is crucial to create genuine shared understanding and buy-in to a product or project vision upfront and then to translate that vision into a product road map or, better still, a story map. Significant changes to these artifacts should be managed through a lean but disciplined review process which might include temporarily halting the team's efforts until the impacts of such changes can be properly assessed and incorporated.

The Greek philosopher Heraclitus might have said that "The only thing that is constant is change" but that doesn't mean we should expect constant change!