Author Archives: Kiron Bondale

About Kiron Bondale

Measurable business value can be realized through the successful initiation, prioritization, planning & execution of strategic projects. Striking a pragmatic, value-based balance between people, process & technology is a key to achieving success with Project Portfolio Management initiatives. Effective change management is crucial when trying to improve PPM or PM capabilities. Having been involved with multiple capability improvement initiatives, what I've learned is that "it's easy in theory, difficult in practice"! Continuous improvement of hard & soft skills gained by assisting organizations in the achievement of their business goals through the execution of the right projects in the right way is my ongoing mission.

Securing contingency reserves is the responsible thing to do!

If you have ever taken a course in project management, you may have learned the differences between contingency and management reserves. The former are used to protect project cost or schedule objectives from the impacts of identified, realized risks whereas the latter are used to address the impacts of unidentified risks. Project managers usually have the authority to utilize contingency reserves as identified risks are realized whereas they would normally seek approval from a higher authority such as a steering committee to use management reserves.

A challenging task faced by many project managers is defending contingency reserve amounts their teams have estimated are required for their projects. Sponsors or customers might understandably be hesitant to tie valuable funds up for events which may not occur as this represents unwanted opportunity costs. Some stakeholders might even be reluctant to think that things might go wrong with their projects. Expected monetary value can be used as part of quantitative risk analysis to justify reserves but that might not be enough to convince stakeholders who don’t see the rationale in putting anything aside for contingency.

In such cases, educating them on why contingency reserves are important by using stories might work.

Ask the stakeholder if they own a home and whether they put any money aside each year for maintenance. Most folks would likely say that they do. Ask them why they do that. They’d likely say it is to avoid their having to cut planned expenses from discretionary accounts when they need to do some repairs or replacements in their homes over the course of the year.

Ask them if they own a car. If they do, ask them why they pay for car insurance. They’d would likely answer that it is to save them from significant repair or liability charges if they get into an accident or if their car gets stolen. Ask them what would happen if they didn’t have insurance and as a result of an accident they needed more money than they could easily free up. They’d likely answer that they’d have to go to their bank and ask for a loan.

Finally, ask if they have teenage kids and if they give those kids a weekly allowance to pay for discretionary purchases. If they do, ask them how they react when their kids spend all of their weekly allowance and have to come to them for more money because they want to buy something.

Management reserves are the equivalent of having to go to our parents or our bank for loans or liquidating other other investments when risks get realized. It is bad enough when we have to request them to protect us from the impacts of unknown unknowns but even worse when they get used for identified, realized risks because we were unable or unwilling to secure contingency reserves.

Contingency reserves should not be considered a nice-to-have expense when budgeting for your projects. Securing them is the responsible thing to do to deal with the uncertainties which are always present when delivering projects.

 

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

Let’s flatten five agile fallacies!

In 2015 I wrote an article intending to debunk some common myths about project management. Like many of you, I spent a reasonable amount of time during my first few years participating in online forums correcting agile misconceptions. Unfortunately, just like lopping heads off the Hydra, every time I’d address one myth, a short time later it would re-emerge. Recognizing the futility of trying to permanently suppress fallacies, I stopped responding to such discussions. However, as I would still like to help, writing an article on five of the most common agile myths will give me a reference to provide to folks in the future.

Agile projects and agile methodologies

There’s no such thing. You can have projects which get delivered by teams using an adaptive life cycle or in which the team elects to use certain agile tools and techniques but unless the project itself is suddenly going to become sentient, it can’t be agile. Agile is not a method (which is what most folks mean when they use the word “methodology”). A team or a company can create a delivery method based on agile values, principles and practices but that is just a single instance of an infinite variety of ways of delivering projects.

We need to do agile

Agile is an adjective, not a noun. Becoming (more) agile should also never be the goal of a team or organization but rather a means to achieving one or more goals. Make it a goal unto itself and the downstream impacts might result in worse outcomes than your current state.

Agile started with the Manifesto

The Manifesto for Agile Software Development is a curation of specific software delivery values and principles. None of these values and principles were revolutionary or novel in 2001 as they had all been identified before in one body of knowledge or another. Concepts, tools and techniques associated with agile have been used for decades and many popular delivery frameworks such as Scrum and XP were published before the Manifesto was written.

To be agile, you must be/have/do “X”

Whether it is sprints, story points, user stories, product owners, servant leadership or any one of a myriad of other roles, tools, techniques and buzz words, the agile community has become really efficient at dividing and conquering itself. Being agile needs to be assessed by outcomes and not merely by how those outcomes were achieved otherwise you risk sliding down the slippery slope to cargo cult.

Agile delivery is better (or worse) than waterfall

Context counts. There is a wide range of possible life cycle choices from fully adaptive to full predictive and very few projects fit cleanly at one end or another of the spectrum. Profiling a project to learn where it falls along this continuum is a critical step for teams to take when tailoring their approach to find better ways of delivering that specific project.

Any others I’ve missed? Feel free to respond in the comments and I’ll add them to the list!

 

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

Planning for those project disasters that no one wants to think about

Harvard Business Review published an article this week about how boards can prepare for unexpected calamities such as pandemics, natural disasters or cyber-attacks. The authors provided a three-pronged approach for dealing with both true black swan events as well as the more common black elephants (a low probability significant threat which leaders are aware of but don’t wish to address proactively). While the strategies provided apply to board members who are looking after the health of their companies, after reading the article I felt they could be adapted to apply to projects as well.

Boards play a key governance role in the successful running of companies. Steering committees play a similar role when it comes to projects. A common mandate for a steering committee is to help guide projects in the right direction by providing ongoing support to the sponsor and project manager. Some steering committees merely play an advisory function whereas others might be more directive. If the sponsor or key risk owners are ignoring looming threats, the steering committee could push them to do more and can encourage these stakeholders to take a more proactive stance. Steering committees can ask these stakeholders the tough questions which project managers or team members might be afraid to ask. To do this, committees need to be staffed with a diverse group of leaders.

Boards are often actively involved in the succession planning process for leadership positions, helping to cue up the best candidates for key leadership roles. Executive teams can play a similar role with projects by identifying who possesses the right risk appetite to be the best sponsor for a project. They can also plan for the future by creating leadership development programs incorporating effective risk management lessons. And, capacity permitting, they can act as mentors for senior stakeholders on critical projects, helping those leaders to plan for the threats they’d rather not think about.

The article also recommends that boards can design or adjust leadership compensation programs to compensate leaders for taking steps which will protect the company from unplanned disruptions. These programs can also be tuned to penalize leaders who prioritize personal short term gains over long term organizational resilience. The same ideas can be used when defining performance plans for sponsors and other key senior project stakeholders. Incorporating project success within the performance plans for these leaders is a good start, but ensuring that the measures also assess how the leaders are going about ensuring success and what they are actively doing to protect against threats is equally important.

The authors close the article by reminding us that building up organizational resilience is a long game. If senior leaders fail to plan for black swans and elephants they will plan to fail when those are realized.

 

 

Categories: Facilitating Organization Change, Project Management | Tags: , , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: