Easy in theory, difficult in practice

A team is unlikely to meet its delivery commitments if its members are constantly relying on the project manager, their people managers or stakeholders to progress. If the project manager calls all the shots, it’s rare that team members will begin to rely on one another and unhealthy tension is likely to emerge as each team member vies for more attention from the dominant stakeholder. While it is more common to see it referenced in the context of agile projects, the idea of a self-managing team can apply equally well to traditionally run projects.

A lot has been written about the ways in which a leader can facilitate team development, but what are some of the key signs of self-managing, high performance teams?

Accountability from within: On self-managing teams, rarely does someone from the outside have to remind a team member of their commitments.  Each team member has a high level of self-discipline but is also keen on ensuring the team’s credibility remains untarnished and they will go out of their way to help or coach fellow team members who are at risk of missing the mark. They will also not hesitate to ostracize or eject a team member who repeatedly demonstrates an inability to help the team progress.

Embedded continuous improvement: The team owns its work practices and continually assesses the effectiveness and efficiency of these practices. When defects occur, the team doesn’t start the “Blame Game” but seeks to identify and implement methods of prevention.

Unconscious yet effective delegation: When a new work item emerges, who will need to work on it rarely needs to be negotiated. Each team member knows and respects the unique abilities of his or her peers and the assignment of activities begins to resemble the ball passing abilities of a high performing, highly cohesive sports team.

Organic onboarding: When a new team member joins, the team as a whole takes the effort to learn about the new team member’s competencies and experience.  In turn, they will also ensure that the newcomer learns the same about the rest of the team and is taught the written and unwritten rules of behavior which the team follows. With such teams, it is also rare that a decision is made to bring on a new team member without the team’s involvement in the recruiting process.

A culture of recognition: Self-managing teams rarely crave or actively seek individual recognition from without. They share equally in the success of the team as a whole, but recognize each other on a daily basis in small ways with simple rituals such as picking up a coffee for a team member who is too busy to go and get one. They also begin to develop a higher level of emotional intelligence with each other which helps them understand when a team member is down and in need of some encouragement.

Sounds like nirvana, doesn’t it?

Two reasons we so rarely see teams demonstrate all of these signs is the authoritative approach used by many project managers, sponsor or people managers and the inability or reluctance for many organizations to form teams which persist from project-to-project.

As with most organizational performance challenges, we have seen the enemy, and he is us.

(This article was originally published by me in December 2014 on my personal blog, kbondale.wordpress.com)

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.

A project lifecycle is very similar to the seasons of the year.

Initiation (Winter): The greatest degree of uncertainty, heavy administrative effort (snow removal or setting up a project – both are equally time consuming!), facilitating the Forming and Storming phases of team building, and meeting and establishing relationships with hostile stakeholders.

Planning (Spring): Uncertainties reduce, our teams are into the Norming phase as we look forward with anticipation and plan for the Summer (execution) but occasional cold spells are similar to the conflicts and negotiation that invariably arise as schedule, cost, scope & quality baselines are defined.

Execution (Summer): A lot of constructive, positive activity and we are in the Performing phase of the team lifecycle.  Periodic thunderstorms are analogous to the “churn” created by project changes.

Closeout (Fall): Project shutdown maintenance and administration combined with supporting your team through the Adjourning/Mourning phase – “impending Winter blues” are very similar to the emotions felt by all as a project ends.

However, we know that as one project ends, a new project will commence, and the seasonal cycle resumes!

In the same fashion as we prepare for each season by performing routine maintenance tasks, your project also requires regular care & feeding.

During the execution phase, it becomes too easy to succumb to the tunnel-vision focus on schedule, scope, cost, issues and team productivity or morale.

Having a checklist to consult can ensure you don’t neglect other important questions such as:

• Is your sponsor engaged & positive about the project?
• Is the project still going to deliver benefits to your organization?
• Have you met with your stakeholders recently and are they aware of what is going on with the project?
• When’s the last time you reviewed your risk register/portfolio with your team & stakeholders?
• How are relations with your vendors?
• Have you received signoff on completed deliverables?

If you only focus on the triple constraint during those halcyon days of execution, you may suffer the same fate as the grasshopper who sang away the days of summer.

(Note: this article was originally published by me in October 2010 on my personal blog, kbondale.wordpress.com)

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)

If managing project after project in your current role is making you feel like a ship adrift in the Sargasso Sea, here are a few potential growth paths:

1. Continue to take on projects with greater scope & larger complexity within your domain.  No matter how large your last project, there’s always a bigger or more challenging one out there.

2. Change domains.  While it can be difficult to transition to managing a project in a domain with which you have no experience, you could seek opportunities that enable you to leverage some of your previous experience while you learn the nuances of a new industry.

3. Go global or go virtual.  If you have only managed local projects & resources, the challenges you will face with remote teams and global stakeholders will be more than made up by the benefits such diversity can bring to a project.

4. Evolve into program management.  Not every project manager is successfully able to transition to program leadership, but for those that do, the increase in strategic work effort combined with closer alignment with business & operations can generate greater job satisfaction and (if you are so inclined) can provide the improved visibility & credibility necessary for promotion to the executive wing.

5. Assess your competencies & specialize.  PMs tend to be versatile generalists, but you may find your experience and interest lend themselves to specializations such as team building, negotiation or troubled project recovery.  While there are certainly some pitfalls in specializing in any career, the big upside in a maturing profession is that differentiation usually encourages longevity.

6. Volunteer.  I know, after a hard day’s (week’s or month’s!) labor, the last thing you may feel like doing is project managing in a volunteer capacity, but you might find that the gratification you get and honest recognition you receive might help to energize your batteries for your normal role.  It doesn’t have to be a significant undertaking – it could start by mentoring a junior PM.

7. Move from vendor to client (or vice versa).  Sufficient time spent in either vendor or internal PM capacities provides some unique insights into the other camp.  Of course, you might find that the grass is not always greener – some personalities are better suited to consulting work while others are better suited to internal roles.

In many roles, re-inventing yourself presents significant risks and could set you back both professionally and financially – is it any surprise that the profession that implements change can also benefit from it the most?

(Note: this article was written by me in May 2011 on my personal blog, kbondale.wordpress.com)