Easy in theory, difficult in practice

Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.

Easier said than done!

It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.

A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.

Although Gantt charts have been around since the early 1900's, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn't also provide some incremental benefits.

This need could arise from any of the following causes:

• Complicated dependencies between the outputs from different teams
• Work streams that are delivered using traditional, deterministic life cycles
• Activities performed by supporting roles working outside of the agile teams

The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success.

If there is a need to have an overall integrated project schedule, the agile teams' sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.

With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.

When qualitatively analyzing risks, we are taught to have our stakeholders estimate the probability of realization and the impacts to project objectives if risks are realized. If we have good historical data or subject matter expertise to rely on, we can take this exercise a step further and attempt to quantify the likelihood of occurrence or the magnitude of the impact. Based on this assessment, risks get prioritized so that we can focus limited efforts on those risks which pose the greatest severity.

But what if we can’t detect when a risk is about to be realized?

For low severity risks this might not seem like a big deal. Our contingency reserves should be sufficient to absorb the impacts of those.

But how about high severity threats? If we have no ability to know when one of those is going to be realized, unless our risk response strategies have focused on minimizing potential impacts, we are still likely to experience some impact to our project’s objectives before our contingency plans take effect.

How about high value opportunities which present a low likelihood of detection? Again, if we don’t have the ability to benefit from them quickly, a delay in implementing plans to exploit them will reduce realized benefits.

Finally, have you ever faced the scenario where you’ve qualitatively analyzed your risks only to realize that based on the estimated probability and impacts, you have a large number of high severity risks? How do you go about prioritizing your risk response efforts and getting the best returns from senior stakeholder engagement?

This is why we should consider leveraging Failure Mode and Effects Analysis (FMEA) practices from product and process design by adding a third dimension to risk evaluation – our likelihood of not detecting imminent realization of the risk.

A low score is given to those risks whose realization will be seen a mile away whereas those with a low chance of detection should receive a higher score. Just as you would do with impact and probability, it’s important to define a standard for the rating with examples to increase the likelihood of consistent evaluation by your stakeholders. There should obviously be alignment between risk triggers and the detection score – the more triggers which can be identified for a given risk, the lower the detection score.

When this new detection rating is multiplied with the traditional probability * impact value, you now should start to see some stratification of your previous uniformly high severity risks – in FMEA terms, this is known as the Risk Priority Number (RPN).

Prioritizing risks using the RPN can improve the efficiency and effectiveness of risk responses. For example, when faced with a high severity risk which has a very low likelihood of detection, response efforts might best be focused on avoiding or transferring the risk if possible.

Charles Duhigg – Between calculated risk and reckless decision-making lies the dividing line between profit & loss.

(Note: this article was originally written and published by me in November 2015 on my personal blog, kbondale.wordpress.com)

Some organizations are experiencing the challenge that while they will need to sustain a significant volume of transformational change to remain competitive or relevant, their existing culture does not have a change appetite.

How would you know if this might be a problem in your company?

A simple survey to a cross-section of your company asking the question “Is the pace of change you’ve experienced over the past year too fast?” might be one place to start.  So long as there was good justification and strategic alignment for the changes that were introduced over the time period, if the general feeling is still that there was still too much change then (pardon the pun!) something needs to change.

Taking a portfolio approach to the timing of changes is one way to address this concern – if there is too much convergence of impacts to a team at a given point in time, and then months where no changes hit them, it’s no wonder if they chafe at this feast or famine situation.  Alternately, if changes are made repeatedly or within a small space of time to the same value flow or business procedure through different projects, it can feel unplanned or chaotic.  Where there is flexibility in project schedule commitments, a portfolio manager should be able to balance business priorities with a steady rollout of changes (instead of a big bang) as well as the bundling of cross-project changes which will impact the same affected area.

Portfolio-wide change implementation consistency can help, but what can an individual project manager do to develop change “muscle memory” for staff?

Delivering projects using agile instead of waterfall lifecycles might be one place to start.  Here are a few of the benefits that this approach may provide.

• Staff get used to experiencing change in smaller doses, more frequently – this is a good way to avoid the risks of “big bang” implementations.
• Team members will begin to embrace change as an essential component of a healthy project instead of trying to avoid it at all costs after requirements have been defined.
• Project sponsors and champions will get better at supporting change as they will have more opportunities to do so over a project’s lifetime.
• Staff will experience the benefits of frequent change if their feedback is solicited and incorporated through refactoring into subsequent implementations within the lifetime of a single project.

In Dune, Frank Herbert wrote “Without change, something sleeps inside us, and seldom awakens. The sleeper must awaken.”  Delivering projects in an agile manner might be just the wakeup call your company’s culture needs!

(Note: this article was originally written and published by me in December 2012 on my personal blog, kbondale.wordpress.com)

Congratulations – you’ve just been given the opportunity to manage a very innovative project – so unique, in fact, that nothing similar has ever been attempted by your organization!

Once the euphoria settles, you realize the significant challenge facing you – how do you go about planning a project without the benefit of expert or historical knowledge?  To make matters worse, if this is a project your company is doing for a paying customer, there are likely to be tangible and/or reputational penalties if you end up significantly missing the mark.

Assuming you have done your research and knowledge of similar projects is not easily available through your professional network, business partners or online sources, some of the following practices may help you out.

• Have your customer articulate what they feel is a minimally acceptable end state, and then have them give you an idea of the relative priority of all other bells and whistles.  This can help you focus your team on working through the complexities of “must have” requirements without being overwhelmed by the “nice to haves”.
• Involve your customer in scope decomposition – they’ve likely spent considerably more time in thinking about the scope than you or you team may have and even though they may not be able to materially help you in answering the “how”, they should be able to refine or focus your understanding of the “what”.
• The more novel the project, the wider should be the skills and backgrounds of invitees to planning sessions.  You don’t know what you don’t know, so by increasing diversity, you should see a resulting increase in the quality of scope definition & decomposition as well as in identifying good approaches to deliver this scope.
• Apply techniques such as Delphi to be able to refine and distill estimates.
• Conduct risk identification sessions with as broad a group of participants as possible.  Not only will this help to unearth risks which you may not have considered, but it will help to overcome biases and may even help to identify scope elements which has been missed earlier.
• Structure the project into multiple phases – the first to deliver a prototype, pilot or model of the desired end state as well as detailed estimates and development plan for delivering complete scope.
• Embrace agile practices and approach the project as a set of iterations or sprints with the focus being on delivering highest priority customer-usable scope first.  That way, if you do find yourself facing the likelihood of going over budget or behind schedule, the customer can elect to cut their losses but still have received value from the work completed to date.  It is also advisable to focus on tackling higher risk, must-have requirements first – knocking those off will give the team a morale boost, and challenges experienced with completing those can help you more accurately re-forecast budget and timelines.
• Where reasonable, negotiate to make working conditions for your team as supportive of creativity and productivity as possible.  You may need to request your customer or sponsor’s influence in getting waivers on your organization’s standard operating procedures if this means that your team will be able to hit the mark more predictably.  Employ project warrooms, collaboration sites or any other types of physical or virtual tactics that can reduce distance between team members and increase knowledge sharing.

How do you eat an elephant?  One bite at a time!

(Note: this article was originally written and published by me in April 2013 on my personal blog, kbondale.wordpress.com)

Organizations that are in the midst of an agile transformation will often track how many projects within their portfolios are being delivered following an agile lifecycle. Obsessing over this number or using it as a basis of comparison, or worse, competition between departments will make it a vanity metric. However, used appropriately, it can be a useful data point for assessing the progress of the transformation.

Knowing how many concurrent projects can be delivered using agile approaches is important because if the organization attempts to execute more than its capacity to deliver, a slew of issues will emerge.

Mandating that core team members will be dedicated to a project or product is important so that many of the beneficial outcomes of agile approaches such as predictable velocity, reduced context switching and increased team cohesion can be achieved. Dedicated product ownership is also needed to ensure that stakeholders needs and wants are being actively solicited and the team is not delayed waiting on decisions or requirement clarification.

But is that enough?

Having sufficient agile leads (e.g. Scrum Masters, XP Coaches) and coaches is also critical to meet increased delivery expectations from business sponsors.

Agile leads need to be focused on a single project. Within that project, they can be supporting more than one team, but to have them juggle different projects will impede their ability to remove blockers, increase alignment and build high-performing teams.

Coaching is needed at the delivery team level but it is equally important to have key stakeholders such as functional managers coached to achieve the necessary mindset and behaviors shifts required for successful adoption. Without this, teams are likely to stall in their agile evolution.

Procuring and retaining competent agile leads and coaches is not easy. They are in high demand due to accelerating demand for agile delivery and finding qualified candidates who have both the experience and cultural fit with your organization is challenging. Like any other hot skill, there will be a limited supply of full-time talent in a geographic area given the number of companies simultaneously conducting agile transformations.

You should certainly have plans being executed to build these skills internally, but this won't happen overnight and if your company has compensation or cultural shortfalls relative to others in the local market, it will be very difficult to build sustained bench strength. You could use contingent staffing to address peaks in demand this is not a long-term, financially viable strategy if increasing organizational agility is truly a strategic objective and not just the "fad du jour". 

But not tackling this will just prove Peter Drucker right "In most organizations, the bottleneck is at the top of the bottle."