Progressive elaboration is the only sane approach to planning!

imageImagine that you are planning a multi-day road trip across the country to a town which you’ve never visited before. Chances are that you will load your smartphone with maps to help you navigate the journey as well as identifying some points of interest and regularly spaced hotels along the way. What are the odds that you will plan your trip down to the hour? For most of us the answer will be pretty slim.

So why is it that some of us continue to develop plans to a level of detail which is unrealistic given the level of information we possess about the project at that point in time?

Some times this could be caused by low organizational project management maturity. Financial policies or methodology standards might require project teams to provide detailed high confidence detailed cost and schedule estimates for the entirety of a project before funding gets released. Depending on the consequences for exceeding such prematurely established baselines, teams learn to play the game by either overly inflating or vastly underestimating in order to secure funding approvals.

However, in other instances the root cause could be the team’s own desire to impose control on the inherently uncontrollable. The allure of detailed plans is compelling because they reinforce the illusion of certainty. Models are at best accurate for the instant in which they were conceived, and without significant effort invested in updating them on a regular basis, their value diminishes rapidly.

What’s fascinating to witness is the anchoring which occurs once a plan has been developed, socialized and baselined. The people who developed the plan will go out of their way to ignore or refute objective evidence that something is amiss.

This reminds me of the sadly all-too-common reports of those who have driven their cars into large bodies of water because they chose to obey their GPS directions blindly instead of their own eyes.

This is not to say that planning is bad.

The old saying of failing to plan equating to planning to fail is evergreen. But two principles muse be respected:

  • Planning is an ongoing project activity and NOT just a phase
  • The level of plan detail should be commensurate with the team’s level of knowledge about the project

Progressive elaboration FTW.

Categories: Agile, Project Management | Tags: , , , , | Leave a comment

Is your methodology a melting pot or a tapestry?

meltingpotIn large organizations it takes a village to deliver a project.

There are multiple internal stakeholders who must collaborate and contribute to generate project success. Many of them will have requirements of their own which they expect will be met. Some of these relate directly to the project’s underlying business rationale whereas others satisfy regulatory or policy compliance needs. On top of those will be other requirements which only serve the intake or engagement needs of specific stakeholders.

When it comes to project management methodologies and supporting systems, having multiple internal stakeholders can be challenging. Each might have their own distinct intake process which they use to receive and analyze project requests and they are also very likely to have some unique informational and control needs. In order to satisfy the combined requirements of all of these partners a project team might have to complete multiple artifacts or update multiple systems. If they don’t do so, they risk being held up at a critical project gate.

Waste, redundancy and bureaucracy give project management a bad name.

While there may be limited opportunities to influence external partners to integrate within our existing methodology or systems, this should be a core objective when engaging internal ones. No doubt there will be resistance at first as anyone would prefer that you meet them on their terms by using their templates or updating their systems. But chances are that their requirements are not currently being fully met, information provided is stale or they are being engaged too late so you could present alignment and consolidation as one path to quality.

Technology can help reduce redundancy through data feeds and integrated workflow, but before you start enhancing or consolidating existing systems the processes which these systems support will need to be aligned. Data elements in core artifacts need to be identified, analyzed, mapped and then merged wherever possible. Quality gates need to be augmented to satisfy not only core project assurance needs but also the objectives of the control partners. Reports will need to be analyzed and bolstered to satisfy the information requirements of a broader audience.

Developing and deploying such a unified project delivery framework is not easy but once the dust settles it could substantially reduce your portfolio delivery costs, improve time to market and boost employee morale.

Sometimes a melting pot is better than a tapestry.

Categories: Facilitating Organization Change, Project Management | Tags: , , , | 2 Comments

Three things you should do whenever someone leaves your project

GoodbyeWe start our projects with a small core team but as we proceed further down the rabbit hole we add team members to support planning and delivery activities. Then as work streams get completed, team size shrinks until we reach project closure where we are back to the original core team. On large, multi-phase projects, team expansion and contraction occurs frequently but even with much smaller projects, it is common to have team members exit before the project itself is completed. Some times this could be the result of their assigned activities being completed, but it can also be caused by external factors such as their being required on a higher priority project or a financially motivated decision to shift their work to a cheaper resource.

There are three things which you should do before any team member departs.

Recognize them publicly

Hopefully this isn’t the first time you’ve taken the opportunity to do so, but it’s especially critical that you thank them publicly and reference specific accomplishments before they leave the project. This will ensure that they will depart on a positive note and will also demonstrate to the team that you are aware of the hard work they are doing.

If project budgets and organization policy permit, give the departing team member a gift card or similar small token along with a small greeting card signed by the whole team. You could also consider sending a note of thanks to their people manager to reinforce the positive relationship you would like to build with that stakeholder and to provide input into the team member’s performance appraisal.

Solicit their feedback

My number one peeve with how project lessons get captured in many organizations is that we wait till the end of a project to harvest this knowledge. That milestone could occur months after a team member has left taking potentially valuable lessons with them!

Take the time to ask the team member how their onboarding experience went, what they liked and disliked about their tasks, and if there was one thing which they would like to see changed about the team’s work practices what that would be. By soliciting this information while the project is running you have the opportunity to eliminate hurdles which might be frustrating other team members.

Facilitate knowledge transfer

How many times have you left a project mid-stream only to find yourself called to provide support days or even weeks afterwards? This is usually caused by poor transition planning and execution.

We tend to think about transition planning when a team member departs before their assigned work has been completed, but even when someone leaves after their scope has been delivered there is still the need to transition project awareness to another team member or to the team as a whole. This could include knowledge of where their deliverables and working artifacts are stored, transfer of system or document access control from them to others, and contact lists of any stakeholders or subject matter experts outside of the project team whom they had been frequently interfacing with.

Closing a phase or the entire project usually involves some formality when it comes to taking the team through the adjourning stage of Tuckman’s Ladder but when team members leave our projects mid-phase we should perform these three transition tasks to avoid realizing the risk in Dave Mustaine’s quote “Moving on, is a simple thing, what it leaves behind is hard.”

 

 

 

Categories: Project Management | Tags: , | Leave a comment

Blog at WordPress.com. The Adventure Journal Theme.

Follow

Get every new post delivered to your Inbox.

Join 325 other followers

%d bloggers like this: