Easy in theory, difficult in practice

My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

How will you know when a risk is about to be realized?

Agile lifecycles can improve change resilience

So what happens when your new project really IS "rocket science”?

How many concurrent projects following an agile delivery approach can your company sustain?

All troubled projects are red, but some projects are more red than others…

Agile lifecycles can improve change resilience

Categories: Agile, Change Management

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)

Posted on: May 17, 2018 06:59 AM | Permalink | Comments (10)

So what happens when your new project really IS "rocket science”?

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)

Posted on: May 15, 2018 06:59 AM | Permalink | Comments (7)

How many concurrent projects following an agile delivery approach can your company sustain?

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

Posted on: May 13, 2018 06:59 AM | Permalink | Comments (11)

Does your PMO hinder or help your agile transformation?

Categories: Agile, Change Management, PMO

An agile project management office might sound to some like an oxymoron, right?

This might be a reasonable assertion as many PMOs were first formed to provide oversight over a portfolio of projects and enforcing standards sounds like the antithesis to agility. But many successful PMOs have evolved beyond governance and control to helping their company reach higher levels of organizational project management maturity, and increasing agility should be complementary and not contradictory to this pursuit.

There are many ways in which PMOs can hamper progress towards greater agility including:

  • Enforcing standards over principles
  • Continuing to apply traditional funding models and prerequisites to agile investments
  • Obsessing over vanity metrics such as velocity or time to market rather than business value delivered or shipped features utilized
  • Evangelizing agile from the ivory tower instead of actively engaging with and supporting teams
  • Failing to inspect and adapt

So what can a PMO do to actively support an agile transformation?

  • Collecting chronic impediments from agile teams, curating and prioritizing them, and championing their elimination by the appropriate senior leaders
  • Having the courage to say "NO!" when a given context is not suitable for using an adaptive approach
  • Advocating for funding to incent early adopters to try new delivery approaches
  • Encouraging staff who possess the right expertise, behaviors and attitude to train and take on Agile Lead/Scrum Master or Product Owner roles with coaching support
  • Examining their own operational processes and leaning them out as much as possible
  • Shifting portfolio reporting from being a manual, onerous process to the automated consumption of information radiators
  • Migrating from an artifact-centric delivery approach to an information-centric model
  • Transforming heavy, gate-based governance to a metrics-driven, exception-based process
  • Working actively with functional managers, procurement, HR and other key stakeholders to change their project engagement models to be more support of adaptive approaches
  • Helping portfolio governance committees to make their investment selection, evaluation and prioritization processes more agile

An agile transformation provides the leadership of a PMO with a good opportunity to review their charter and service catalog - are these still relevant, and if not, what can be changed to ensure that the PMO is not identified as common impediment by agile teams!

Posted on: May 06, 2018 07:00 AM | Permalink | Comments (8)

Don’t be an Ostrich!

A systemic lack of predictability regarding resource availability threatens to trump unmanaged scope creep, technical complexity and organization change resistance as the primary source of project risks.  Achieving an organization’s strategic objectives gets impacted as transformational projects require specialized skills that are in high demand and in low supply – this was admirably depicted by Scott Adams in an old Dilbert cartoon

The obvious solution to this is to either add more resources or take on less work in parallel. The first choice is usually unrealistic and success with the second is not achieved overnight.  Reducing the volume of multitasking is a key to more predictable throughput, but convincing senior management that you can actually do more by doing less is not easy. 

In the interim, here are a few tactical steps that a project manager can take:

  • Pity the poor resource manager who has competing demands on his/her resources’ time!  Unless your organization follows an objective project prioritization approach, priorities are likely set by whoever screams loudest.  In this situation, your best chance of improving resource availability predictability is to have a positive relationship with these resource managers so that they will try to be as considerate as possible with your resource needs.  If you are really lucky, they may even be motivated to assess and modify the resources’ operational duties to help you out.
  • Reduce the degree of project internal multitasking – it’s bad enough that your team members are likely working on other projects as well as operational activities, but at least try to avoid their having to context switch between tasks on your project.
  • Multitasking creates inefficiency as a result of context switching. Reduce the effort wasted in context switching by simplifying the ramp up/ramp down for team members.  One way to do this is to decompose work activities to a low enough level of detail, so individual tasks can be accomplished within one or two context switching cycles at most.
  • If your organization does not have a standard PM methodology, work with your peer project managers to define a consistent set of expectations for team member progress and issue management.  If a resource knows that the reporting requirements are consistent across the concurrent projects they are assigned to, that’s one less thing for them to worry about learning (and re-learning!).
  • Walk a mile in their shoes. When team members have multiple projects and operational activities to complete, increase the likelihood that they will want to work on yours by ensuring they understand how their tasks (and the success of the project as a whole) will benefit the organization and them.  Remove as many barriers to their being able to efficiently complete their tasks as possible. That means no unnecessary meetings and be sure to streamline project administration and communications as much as possible!  Take a page from agile approaches and embrace the role of a project manager as being responsible for clearing the hurdles from the team’s path.

Resource availability unpredictability is here to stay. You can make like an ostrich, stick your head in the sand and hope the problem goes away. Or you can take some tactical steps to increase the odds of success for your project, while simultaneously evangelizing the merits of reduced multitasking!

Which is it to be?

(Note: this article was originally written and published by me in June 2010 on Projecttimes.com)

Posted on: April 24, 2018 07:00 AM | Permalink | Comments (16)

"Hard work never killed anybody, but why take a chance?"

- Charlie McCarthy (Edgar Bergen)



Vendor Events

See all Vendor Events