Just when I thought I was out (of this project)… they pull me back in!

A common phenomenon in some organizations is that project managers experience great difficulty in being able to fully disengage from a completed project.

While in extreme situations this can impact their availability to take on their next project assignment, in most cases they are able to start work on a new project but will still find themselves performing some ongoing activities related to their last or even their last few projects.

Assuming that this is not a desirable scenario, three likely causes are:

1. Incomplete project scope – if critical deliverables were not completed or not fully accepted by the project’s customer, the project manager might have been successful in closing the project and reflecting gaps these as exceptions, but work may still be continuing and stakeholders might expect the project manager to manage and keep them updated on the progress of this post-project work.
2. Insufficient knowledge transfer to operational teams – if the operational teams that are expected to provide support for the project’s deliverables have not developed sufficient expertise to be able to fulfill their responsibilities, staff will feel inclined to continue to solicit assistance from the team members or project manager well beyond the project’s completion date.
3. Poorly defined governance processes or staffing of roles to support these governance processes –  on technology projects which are delivering a new business system or process, there will be the need to establish basic governance to manage ongoing changes to the system or process.  There may also be the need to identify an information owner for the information assets stored within a new business system.  Inadequate process definition or staffing of such roles may result in staff seeking assistance from the project manager to help facilitate changes to the system or processes.

What are some tactics to help project managers avoid incurring this operational project debt?

• Ensure that transition deliverables are well defined, planned & sufficiently staffed
• Avoid prematurely closing the project as soon as key deliverables have been completed
• Insist on signoff on the project closeout report from operations managers as reflecting their readiness to effectively support the project deliverables
• Request formal signoff from project customers on key project deliverables and ensure that any post-project work has an owner
• Conduct User and Production Acceptance Tests on governance processes to verify that they are in fact usable and appropriately staffed
• Cultivate subject-matter experts & champions for the project’s deliverables from outside of the project team through the latter stages of the project’s lifetime

Mick Jagger might have said “A good thing never ends” but he was obviously not referring to projects!

 

 

 

The Serenity Prayer is a mantra for project managers

An unfortunate analogy that can be made of project managers is that in many respects they are like worrying parents.  They invest a significant amount of effort, credibility and emotion into the nurturing of their projects, so anything that is likely to impact the success of their ”offspring” is going to affect them in a very similar fashion.

There is a broad range to this type of behavior - some parents (usually those who have more than one child) are mature enough to monitor things from a distance but to also be prepared to act if required whereas others micro-manage their kids lives to the point of almost smothering them in bubble wrap!  The same can be said about project managers – some trust their team members and stakeholders to be professional enough to come to them proactively when concerns are identified, whereas others won’t be comfortable if they are not constantly “touching base” to make sure all is well.  This behavior extends beyond risk and issue management to quality – just as some parents have the need to mold and hammer their children to fit the parents’ vision of how they should turn out, some project managers exhibit the irresistible urge to constantly tweak or tune deliverables, frequently alienating their teams in the process.

While such behavior is detrimental to healthy team development and the perceptions created can linger well beyond the lifetime of an individual project, it is also not conducive to a good work-life balance.  Project managers who demonstrate the compelling need to stay on top of absolutely everything and to worry past the point of reason can end up neglecting spending quality time with their families or their own professional development.  When challenged about their lack of attention to these critical activities they will rarely indicate that they felt they could have taken an alternative course of action.

Should a project manager be vigilant and take ownership for getting actions, issues & risks addressed – absolutely, if not, they will likely satisfy one or more of Neal Whitten’s ten signs of “too soft” project management behavior!  However a project manager also must recognize the limits of their ability to positively influence project outcomes – in spite of these efforts, the project may still suffer for reasons outside of their control.  This is where that critical but elusive project management competency of judgment is required to help them accept the things they cannot change, draw on courage to change the things they can and have the wisdom to know the difference.

Yes Virginia, there really ARE PM tools which can support both agile and waterfall projects!

A challenge faced by organizations attempting to adopt agile practices is deciding what project management documents are valuable – which traditional lifecycle ones should be maintained and which can be discarded?

This is more common than one might assume owing to the reality that very few companies are able to implement a specific agile methodology exactly as this is usually not going to meet the needs of all of the different types of projects within their portfolios. What works well for a “start-from-scratch” application development project may not suit the needs of a business process improvement engineering initiative even though agile principles could help both.

While this is not intended to be an exhaustive list, here are some of the documents which should be used regardless of whether a waterfall, pure agile, or hybrid approach is followed.

• Project charter: In its most basic form, the charter authorizes the existence of the project and helps to align customer, stakeholders, and team on the expected outcome for the project. Without an approved, distributed charter, the team runs the risk of significant shifts in overall project direction beyond those which even agile approaches can address.
• Project plan: Size, content and structure can vary between projects, but there is still the need for a document which formalizes governance structure and processes for the project, identifies assumptions, prioritized constraints, resource requirements and provides an understanding as to how the project scope will be delivered and over what timeline. This latter information could be documented using a WBS and schedule on a traditional project, or via a work items backlog and iteration or sprint roadmap on an agile project.
• Decision records/requests: Regardless of how flexible a project is, there are going to be key decisions on which fundamental project outputs rely which should be formally documented, approved and shared. The volume of these is likely to be smaller on agile projects as compared with traditional projects.
• Change requests: Similar to decision requests, while these might be used to a lesser extent on agile projects given the likelihood of scope being the most variable constraint, there is still the need to formally acknowledge the decision of the customer to extend or reduce other constraints. One example of this might be the decision to close the project after the completion of the current sprint if the customer’s needs are met in fewer sprints than originally planned.
• Risk register: A disciplined risk management process is critical for both agile and traditional projects otherwise team velocity is likely to be a fairly unpredictable forecasting measure.
• Action and Issue logs: Although these are less used by the team on an agile project due to the use of standup scrums or similar tactics, the role of the PM is to remove hurdles from the team’s path and these logs will be a crucial communication tool with key stakeholders.
• Status reports: Performance measures will vary between agile and waterfall projects, but there is still the need to keep key stakeholders apprised of quantitative and qualitative information on a regular basis.
• Project close out report: Although this report can contain significantly more, at its most basic, it should provide an understanding of what was accomplished or delivered vs. what was expected/planned, and list outstanding activities or next steps to facilitate transition.

Purists from both waterfall and agile schools are likely to take exception to what they may perceive as too short or too long a list of PM documents. As with most PM practices, this list only reflects the “what” and not the “how” (or rather, “how big”) – that I leave to the individual practitioner as “just right” is always in the eye of the Ursine beholder!