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:
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.
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.
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."