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."
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:
So what can a PMO do to actively support an agile transformation?
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!
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:
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)