Many project managers have doubtless exclaimed “giving birth would be simpler than managing this project”! This may be truer than they ever imagined…
Initiation can provide the same euphoria as finding out you are going to be a new parent – getting assigned to a new project is an exciting but also unnerving time. There are hundreds of questions, but also plenty of stakeholder input! There are myriads of sources of information, but it can be challenging to separate the useful lessons learned from “old wives tales”!
Planning can prove to be as unpleasant as the first trimester – with frustrating stakeholders, challenging constraints, uncertain scope and storming teams, project managers might be excused for acting as though they suffer from prolonged morning sickness! With appropriate attention & resourcing combined with a healthy dose of risk management, the project manager should strive to lay a solid foundation for the rest of their project/pregnancy.
Project execution can feel a lot like the second and most of the third trimesters. This is where the (literally) heavy lifting takes place, the peak resourcing/food intake, and careful monitoring & tracking of vitals, but if planning was done well, it should be a fairly smooth ride. Resource shortfalls need to be addressed in a timely fashion to avoid impacting the project’s outcomes and cutting corners on quality will come back to haunt you long after the project/baby has been delivered! While change is to be expected, it should not be rushed into without appropriate governance. The need to prepare the environment for the impending arrival is also crucial. Procrastination on implementing effective organization change management will be extremely costly as anyone that has had to decorate a baby nursery at the last minute will attest!
Finally, project closeout can range from the very smooth to the highly painful. Challenging project “deliveries” can be the result of poor planning and execution, but they might also be through no fault of the project team’s, but rather a result of external or environmental factors. Closeout can also be a time of intense conflict between the project team and key stakeholders (e.g. mother-in-laws, new fathers)!
Throughout the project/pregnancy, the need for effective, timely communication is critical.
Having a baby is the first step in a long rewarding journey for new parents just as successfully managing a project should be the start of achieving expected business outcomes.
(Note: this bouncing baby blog post was originally brought into this world in September 2012 on my personal blog, kbondale.wordpress.com)
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:
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)