In one of my previous articles I'd written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization's model for project funding will have significant influence over successful agile delivery.
Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.
The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.
So what challenges arise from a project-centric funding model?
It can result in higher risk, premature financial commitments.
Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint's worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.
Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?
It can also encourage sloppy product management.
When product owners receive funding for a single project and don't have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product's capabilities.
Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.
Ask someone which delivery roles are critical to successfully completing a project and you will get a wide range of recommendations. Three of the more common roles likely to be stated include a project lead, a requirements lead and a solution lead. This is logical as the first is responsible for the delivery process, the second what needs to be delivered and the third how it will be delivered.
But aren’t we missing a vital role on most projects?
Sponsors are funding our projects to realize expected business outcomes and these outcomes are achieved through successful change implementation and not just by completing project deliverables.
Your core delivery team should be the Four Musketeers instead of the Three Amigos through the addition of a change lead.
On small, low complexity projects, a person fulfilling the project lead or requirements lead role might be able to wear more than one hat and take on a change lead role but the same reasons apply for not doing this on larger, more complex projects as would for combining the project lead and solution lead roles.
It’s a question of both capacity and capability.
The more complex a project, the greater the likelihood of the project or requirements lead focusing on the current stage and progress of the project and its deliverables rather than planning and preparing for successful change adoption and sustainment. While they will be actively engaging with stakeholders, the conversation might not stray into post-project topics. While good project and requirements leads are expected to possess advanced soft skills, the emphasis on specific soft skills required to be a successful change lead will vary from those for the other roles.
Looking beyond delivery risk a change lead has the ability to elevate the visibility of execution and operational risks caused by or impacting a project. One example of these is change storms which result when multiple projects and operational events impact a specific stakeholder community within a short period of time.
Change leads are more than just a nice-to-have role on most projects, yet are often ignored or eliminated through a myopic focus on cost containment.
You get what you pay for.
(Note: this article was originally written by me in December 2016 on my personal blog, kbondale.wordpress.com)
When companies identify a capability gap in one of their business areas, it is common to bring in outside assistance to help assess and fill this gap. Generically, this would seem to be common sense – if I know that I need to improve my knowledge of plumbing, I am likely to fare better if I hire a professional plumber than if I try to figure things out on my own (even if there are some really good YouTube videos available on home improvement)!
However, when it comes to project management effectiveness, the merits of this practice are questionable. No doubt, a consulting firm that specializes in delivering such services is likely to have more focused capability improvement experience than the knowledge of your project management team but your gap is rarely about tools and techniques (which are easy to fix) and more about behavior modification at multiple levels of your organization.
The companies that may benefit the most from a focused consulting engagement are those at either the lowest level of project management maturity, or those at a higher-than-average one.
At the lower end of the spectrum, they may not have the shared knowledge to institute even the most basic project governance and management practices, and yet, if there is internal support from the top-down, they could achieve some quick wins by adopting some “out-of-the-box” generic practices coupled with some foundation PM training for all project-involved staff.
For those near-world class organizations, a consulting gig can help to identify and address the few remaining areas for improvement or could ensure that their self-assessment of capability superiority is, in fact, accurate.
For the larger group of companies that have instituted project management practices and tools but are struggling with achieving the behavior changes essential to realizing project management’s true benefits, utilizing external consultants is unlikely to provide any more benefit than an internally staffed improvement initiative. For such organizations, the value of project management is conceptually understood by all but the challenge exists with “walking the walk”. It’s a sure sign of this state of limbo if the majority of the lessons captured in post-project reviews are behavioral reminders.
Don’t get me wrong – significant value can be delivered by an external firm that provides executive coaching and training to your leadership team to help them truly absorb the value of project management and can facilitate the implementation of standard practices. However, unless your organization is ready to engage these consultants for a long-term sustained on-site (i.e. costly) campaign, it is unlikely that they will be able to truly influence positive behavior changes.
Unfortunately achieving higher levels of project management maturity is often a case of “Physician, heal thyself”!
(Note: this article was originally written and published by me in August 2012 on my personal blog, kbondale.wordpress.com)
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.
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)