pm-lotus by Howard Vaughan

Project Management and Culture - not always love at first sight

One of the most critical success factors in implementing project management is ensuring the right fit of processes and systems with the culture of the organization. Yet culture is such a wonderfully complex and seemingly amorphous thing that it can be hard to know what “fit” really means if we can’t define the characteristics and boundaries of the firm’s culture.

The Re-Engineering Alternative by William Schneider provides both a fascinating insight into organizational culture as well as a practical toolkit for determining your own company’s core culture. This is not a new book but it is a gem. Designed as an aid to improving organizational effectiveness by leveraging cultural norms and behaviors, Schneider describes how peeling back the layers of any organization will yield one of four dominant culture types.

Understand Your Culture

Each culture is defined in fine detail by comprehensively describing the leadership and management styles, strengths and weaknesses, structure, relationships and decision-making attributes that characterize them. Discovering the differences will help explain why organizations operate the way they do and, by extrapolation, why project management has to be tailored to be sustainable. Schneider terms the cultures as:

• Control - structured, domineering, task-oriented
• Collaboration - trust-based, empowering, people-centric
• Competence - achievement-oriented, impersonal, excellence-driven
• Cultivation - potential-fulfilling, creative, informal

If you’ve worked in a variety of culturally diverse organizations, you’ll quickly recognize the distinctive traits of each of these four cultures that are described in the book so clearly and with plenty of examples.

Culture Limits Execution of Strategy

As Schneider rightly points out, culture limits strategy. And since culture sets expectations, priorities, managerial practices and communication patterns, it also limits the execution of strategy – and therefore projects. Culture ultimately defines how work is planned, organized and managed – which is why it is such a crucial consideration in any effort to improve enterprise project management.

Knowing the latest dates that we can start and finish tasks without impacting the overall project schedule is key to effective time management, especially for those projects where schedule is the least flexible component (see Flexibility Matrix).

Like the critical path itself however, Microsoft Project does not display this information by default. But we can easily set up the display options to reflect the late dates as in the example below:

Here’s how we configure this. First we display the critical path:

• From the menu, select View, Gantt Chart
• Then click the Gantt Chart Wizard button on the Formatting toolbar
• Select “Critical Path”, then Finish, Format It, Exit Wizard.

The critical path tasks are now visible in red. Next we set up the late schedule for the noncritical (blue) tasks:

• On the menu, select Format, Bar Styles
• Then click Insert Row to add a row just above the Critical Path display row (note that inserting a row at the top of the list may not work)
• Enter “Late Schedule” for the ‘Name’ and select your preferred bar styles for the ‘Appearance’ - (in the example above I used a navy horizontal line bounded by small triangles)
• Select “Normal, Noncritical” for ‘Show For … Tasks’
• Lastly ensure that you select ‘From’ “Late Start” and ‘To’ “Late Finish”
• Click “OK”

Now you should see the late schedule bars showing for the noncritical tasks indicating the latest each task can start and finish.

Useful Information

Showing the columns for Total Slack (the difference between the early and late dates) and Free Slack (how long a task can be delayed without delaying a sucessor task) as in the simple example above tells us the following:

• The critical path runs through tasks E, G, J
• The noncritical tasks have varying total slack
  • Tasks B, C, H, L have only 2 days, so are near critical and should be monitored closely for any slippage
  • Tasks A, K have 7 days
  • Task F can be delayed by up to 11 days before the project finish date is impacted
• Tasks B and C have zero free slack so any delay will immediately impact their successor tasks

Track the Slack

Knowing not only which tasks are critical and which are not, but also how much float or slack there is on each non-critical task, helps us prioritize work (according to slack value) and monitor trends in schedule variance (changes in slack week-to-week).

Project management is a blend of processes and procedures, the skills and knowledge of the project community, and tools for assisting with the application of process and knowledge. Good project management is when these three are properly tailored to the needs of the organization, its projects and their teams.

How It Goes Wrong

Corporate initiatives to improve project management sometimes fall short of their goals when these three elements are (a) incomplete, (b) not customized, and (c) treated in the wrong order. For example:

(a)    Training is conducted in process but no tools are provided for follow-up application
- a sure way to minimize training ROI

(b)   Training is conducted in processes that are too generic, too lightweight or too onerous
- very common, leaves PMs to figure it out for themselves

(c)   Project managers are given project management tools without prior training in process
- the “seduction of software”, usually results in poor quality information and plans that are plain wrong

It’s a repetitive scenario and goes some way to explaining the plethora of statistics on failed projects and generally poor project performance.

Right Focus, Right Sequence

The swiftest and most effective way to raise the bar of project management capability and performance is to ensure process, people and tools are treated in an integrated way with appropriate focus on each at the right time. Here’s how:

1. Define a process that fits the organization’s projects and culture
   (proper tailoring is critical to ensure buy-in and long term success)
2. Provide training in this process
   (we’re talking lifecycle here, not PMBOK knowledge areas)
3. Follow-up immediately (even simultaneously) with hands-on tools training
   (custom templates and project management software)
4. Then finally, ensure that support structures are in place
   e.g. a PMO and coaching, to embed the disciplines and practices for the long term.

Done right, it’s a recipe for sustained success.

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

• Are defined by the deliverable or task owner
• Clearly state the characteristics and attributes of the output  – “what done looks like”
• May include the measurement and validation requirement – e.g. “who reviews what”
• Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.

Every project should be closed with a proper review of lessons learned. I’m always amazed at the tremendous amount of feedback, ideas and value that comes out of a well run project closeout review session. Regrouping the team for this one final meeting is one of the most important events in the life of the project.

The agenda for this meeting – best run as a facilitated workshop – should comprise these three items:

1 – What Worked?
2 – What did Not Work?
3 – What must we Do Differently Next Time?

Structure for Best Results

Some structure around each of these will maximize the quality of the output. For example, solicit feedback with respect to specific areas, such as:

• Categories – Planning, Resourcing, Risk Management, Requirements, Technology
• Enablers – Commitment, Competence, Communications (see The Fifth Law)
• Phases – Solution Design, Development, Testing, Deployment.

This provides proper focus and balance for identifying lessons learned. Also, use of the Nominal Group Technique in the workshop ensures the optimal mix of individual contributions and team discussion.

Lastly, just capturing lessons learned is only half the job. In the spirit of ‘kaizen‘ or continuous improvement, they each need to be transformed into action items for implementation, in order to guarantee future projects will use them.

It’s that time of the year when we give thanks, reflect on the year’s achievements and challenges – our own plan vs. actual – and perhaps consider some personal goal-setting for the New Year.

So I’d like to express my own gratitude to all of you who have read, commented on and subscribed to my new blog. Thankyou. Here’s to an outstanding and rewarding 2010.

Merry Christmas and a Happy New Year!

There are countless variations on content for project progress reports but there are ten items that should be on every report:

1 – Business Context
Why does this project exist?
Briefly summarize the desired business outcomes as a reminder to all of the rationale for doing the project – and include the names of the sponsor and customer.

2 – Objectives
What are the project’s tactical objectives?
Always keep the schedule, scope and resource goals in view. The Project Objective Statement provides a concise way of describing these.

3 – Flexibility Matrix
Which is least flexible – schedule, scope, resources?
Reflect the Flexibility Matrix on the report to remind stakeholders of the project priorities.

4 – Schedule
What is the schedule performance of the project?
Identify variance of current progress and forecasts against the baseline schedule for key milestones, phases and/or deliverables. Better yet, include performance trends over the past few reporting periods.

5 – Cost/Resources
Is the project meeting cost and/or staffing targets?
Point out significant variances with the plan such as staffing shortfalls or cost overruns.

6 – Risks
What significant risks exist?
Highlight those risks of highest severity and in particular those with high impact that may occur soon.

7 – Issues
What significant issues remain unresolved?
Identify the key issues and what is preventing their resolution.

8 – Changes
What changes have occurred?
Identify any major changes that were approved and/or implemented since the last progress report.

9 – Accomplishments
What has been achieved?
Capture the most important recent accomplishments such as completed deliverables, milestones that were met, or finished major work components.

10 – Next Steps
What major components of work remain?
Indicate what the focus will be for the immediate future and set expectations of what will be reported on in the next progress report.

Configuring these vital ten into a 1-page format is ideal for executive presentation. These items are of course in addition to the more obvious title and subtitle mentions of project name, report date and author/project manager name. (Surprising how often the obvious gets overlooked).

Getting there - slowly

It’s good to see more organizations finally getting serious about project portfolio management. But why is it taking so long? While all the process elements have been understood by an enlightened few for many years, progress in putting portfolio management into widespread practice has been disappointingly lethargic.

The reality is that most organizations have a great deal to do to make portfolio management work for them. Meaningful portfolio management standards and usable software applications have been painfully slow to emerge. In addition, several pitfalls often derail implementation efforts. Here are four of the biggest:

Lack of Ownership

Managing a portfolio is the responsibility of executives and this is a message that does not always get driven home. Portfolio management provides the crucial linkage of project work with strategy and ultimately the enabler of that strategy. It is not just another level of tactical project management. Executives have to take ownership, get firmly involved and be supportive.

Ineffective Process

In the same way as projects need some form of process to facilitate successful execution, a portfolio requires a structured methodology for establishing oversight procedures, prioritizing projects, balancing resource capacity and demand, and optimizing project funding, scoping, integration, sequencing and resourcing for strategic value. Portfolio management is a discipline.

Mismatch with Maturity

Often lost in the conversations about project prioritization frameworks and strategic alignment is the simple fact that without solid planning and tracking at the individual project level, portfolio management can never achieve its primary goals. Proper portfolio management needs proper project management.

Misalignment with Culture

Portfolio management, like project management, is scalable. It has to be designed to fit the organization’s culture and the way in which decisions are made and work gets done. Misaligning the intensity of portfolio information needs, analysis and control with a firm’s culture is a guaranteed showstopper. Each activity should not only deliver real value – it has to be widely supported.

The Good News

On a positive note, portfolio management is getting increased executive level attention. There is a realization that the option to “Do Nothing” incurs a very significant cost in unrealized strategies, overstretched and demoralized project teams, a lack of knowledge and control over what’s really going on, and dissatisfied customers. No longer can organizations afford not to respond. The call to action is gaining traction.

It doesn't have to be complicated

It shouldn’t be hard but giving thanks to team members doesn’t always come easy to project managers. Yet those two small words “thank you” can sustain an individual’s drive and enthusiasm long after the project is completed.

Whether for overcoming adversity, going the extra mile for the customer, infusing the team with drive and energy or just plain hard work, thanking contributors for all forms of outstanding performance should be high on the daily watch-list of any project manager.

Acknowledgement should be expressed in the following ways:

Honestly

• If it doesn’t come from the heart it won’t be valued. And mixed messages, such as conflicting verbal and non-verbal communication, imply insincerity – thanks that will be quickly discounted by its recipient.

Consistently

• Recognizing one person’s achievement but overlooking another’s is the swiftest way to divide a team. Staying in touch with the challenges on the ground and paying attention to what’s really going on in the team is crucial.

Openly

• There’s no point in keeping gratitude behind closed doors. Proclaim it, proudly. Thanking someone publicly, in front of the team, demonstrates how important it really is and sends a meaningful message that inspires and motivates.

A little thanks goes a long way.

There are several methods for identifying project risks but the best approach involves the team (at least the core team members and any relevant SMEs and/or PMO staff) and considers the following:

• History (review past projects of a similar nature – surprising how often this is missed)
• Context (assess the stakeholders, implementation environment and constraints)
• Boundaries (review the project’s SOW, scope and deliverables)
• Details (review the WBS, dependencies, estimates and resourcing)

The Nominal Group Technique

To get optimum input on possible project risks, there is no better team method than NGT. It leverages the advantage of multiple perspectives, can be done relatively quickly and avoids all the pitfalls of brainstorming, which is over-used and usually poorly facilitated. Here’s how NGT works for risk identification:

1. Each individual reviews history, context, boundaries and details (as defined above) and writes down their own list of possible risks – i.e. with no interaction between members
2. With the team grouped together, all identified risks are then captured by going around the team, taking the first item on each person’s list, then around again capturing the second item and so on until all items have been captured
3. Duplicates are removed from the consolidated list and descriptions clarified as needed
4. Each person reviews all the risks captured and the team decides if any should be removed the listing, on the basis of being extremely unlikely AND with little or no impact

Once this process is complete, the team can move to assessing the severity of the remaining risks, prioritizing them and defining response strategies to manage them.

Lots of Benefits, not much Downside

Using NGT is a great way of aligning the team on project risks. Its thorough, avoids groupthink, rapidly builds awareness, avoids jumping prematurely into risk analysis and prevents outspoken individuals unduly dominating the final risk list.