Voices on Project Management

> Back to Voices Home

January 2010 Archives

Is This Your Project Stakeholder--The Conclusion

| | Comments (3) | TrackBacks (0)
My last post received a wide range of comments and I wanted to draw some conclusions based on those comments and my thoughts.

The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why?

The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program.

As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence.

As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization.

Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis.

The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented.

Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes.

If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager.

A PMBOK® Guide for the Trenches

| | Comments (4) | TrackBacks (0)
When you are introduced into a project environment, with a team who has never used project management and knows little of it, what is going to help most? Is A Guide to the Project Management Body of Knowledge (PMBOK® Guide) too airy and sophisticated?

Put another way, if you find yourself in a World War I-era trench, which would you rather have: the operator's manual on your howitzer or The Art of War by Sun Tzu?

Over my next few posts, I want to introduce my own version of the PMBOK® Guide, unencumbered by peer review (or even consistency). It will give me a chance to cut through some of the academic cobwebs that may have set into our practices, and illuminate recent issues and problems.

We'll start with scope.

Scope: (noun) the output or outcome for which your customer is willing to pay.

You've probably already recognized that, by this definition, the customer can't request anything out of scope, since what they desire is, by definition, in scope. And you would be correct.

So, if you don't want to find yourself in a situation where your (paying) customer is asking for more than you were originally willing to produce for a certain price, you had better have a very detailed agreement--otherwise, that most deadly of project ruination elements, scope creep, will devastate you, your team, your organization and your project.

Here's further proof that my definition for scope is correct: If your customer wants to add work to your project and will to pay for it, what project manager would refuse to do it on the grounds that it wasn't in the original statement of work?

No matter how absurdly the original work breakdown structure (WBS) was set up, if a person with sufficient organizational clout generated it, it can never be substantially changed.

In fact, the very act of pointing out that a proposed WBS element is inappropriate is a serious career-limiting move, since everyone knows that the ability to create a valid WBS is the litmus test for real project managers and pretenders. I've found that the pretenders will attack any challenge with a ferocity rooted in their insecurity.

Yes, it all begins with scope, but it obviously doesn't end there. 

Next up: schedule.

Project Lessons From Parenthood

| | Comments (8) | TrackBacks (0)
By the time you read this, it will have been more than a month since my initiation into the fatherhood club with the most adorable baby boy in the whole wide world.

Through all the diaper changes, sleepless nights and incessant worrying about the baby's health, I began to reflect from a whole new perspective on some project management truisms:. 

Like a baby, projects begin to stink when the schedule fails to be updated or changed on a timely basis.

A year ago, my organization received a letter from a customer saying its independent auditor raised the red flag that a large, complex program we were running had overrun its budget by 20 percent. The customer was demanding to know why we hadn't notified them as required by contract.

The situation was embarrassing; the root cause turned out to be that the program schedule data (including cost information) was grossly inaccurate because it had not been updated.

When a customer cries, project managers, like parents, sense the urgency and react instinctively but often fail to take a moment and decipher the root cause.
Many times I have had the "pleasure" of putting on my firefighter hat to react rapidly to a customer request.

In one instance a customer was upset that based on our latest schedule submission, they would have to report a slip to their management. When our team started the variance analysis as demanded by the customer, someone noticed that the status file submitted to the customer contained last month's data but was mislabeled with this month's date. Problem solved.

Project managers, like parents, are constantly being bombarded with best practices and new or revised processes and methodologies that if utilized would ensure their projects never get sick.

I am quite guilty on this last item since I'm always anxious to apply the latest and greatest.

Then again, maybe if we apply lean Six Sigma with theory of constraint in conjunction with critical chain management coupled with extreme agile iterative spiral methodologies with capability maturity model integration and PRINCE2 and information technology infrastructure library and AS9100 and ISO9000 wrapped around the whole thing, our projects would never succumb to failure again...

Love to hear your thoughts and best wishes to you all!

Pick Your Commitments

| | Comments (0) | TrackBacks (0)
When we work on a project, we commit to tasks that work toward the grand result.

You have these tasks because at some point in time in the past you
have committed yourself to doing them.

Taking on many commitments can make you feel powerful at times, but not delivering on the expected result is a total loss of that power.

Here are some tips for managing your commitments:

1. Get really clear on the particular project requirements and what role you play.

2. Clear your plate of any commitments that do not contribute to the project's end goal.

3.Commit to your role within the project.

4. Commit to the number one task: always delivering on your commitment.

5. Ask yourself daily: What did I commit to doing today? Am I in a position to deliver on those commitments?

It's best to break a commitment ahead of time--leaving you free to execute exactly what you need to be doing.

How do you manage to commit only to what you know you need to achieve?

In the future I will discuss more about how to break commitments not in line with your goals. 

Is This Your Project Stakeholder?

| | Comments (28) | TrackBacks (0)
Imagine for a moment your organization has decided on a major restructure, and as a consequence has initiated a change-management process and appointed a change

The change manager develops the business case for a major program of work. The executives responsible for the organization's portfolio management approve the business case and agree to fund and resource the program.

The program manager sets up the program management team, establishes the program
management office and charters a series of projects to develop the various deliverables needed to implement the change. And you have been appointed project manager for one of the projects.

In this situation, your life as a project manager would be fairly straightforward; you have direct-line management responsibility to the program manager, and the change manager is your project sponsor. The program management office looks after most of the issues of sourcing adequate funds and resources.

All you have to do is deliver the project's outputs as defined in the project charter.

However, part of your project ideally needs the cooperative input from a group of people
who will be significantly disadvantaged by the overall reorganization. This group is led by a 20-year veteran of the organization, whom we will call Mary. At the moment, Mary's loyalties are divided--at one level she wants what's best for the organization she has worked for all her life, but she also wants to preserve her team and keep the status quo.

Fortunately, you have enough domain knowledge in your team to bypass her input and produce the deliverables anyway. So what should you do?

Option one is to work to get Mary and her team's input--if not their positive cooperation--but risk delaying your project's completion and overspending the budget.

Option two is to use the knowledge you already have in the team to produce the deliverable and bypass the problem, thereby ensuring on-time and on-budget delivery. This option also minimizes the chance of Mary interfering in the overall work of the project and program.

What would be your recommendation to the program manager? Option one, two or something different? Post your thoughts in the "comments" section and we shall draw some conclusions in my next post.

What Every Entrepreneur Needs to Know

| | Comments (12) | TrackBacks (0)
My CEO always told me that to be a good project manager, you must be an entrepreneur.

I took that seriously and started my own part-time business.

And I discovered that to be a good entrepreneur requires a lot of project management experience.

For instance, project management skills help me efficiently manage and track my resources. I don't spend more than one or two hours a day on my business, but I have clear visibility about the inventory, orders and payments. the salespeople input their data in a custom-made Excel tool and I get a daily summary report.

I also rely on my project management skills for handling vendors and suppliers. They do not over-commit, but rather rely on a well-defined scope of work and regular follow-ups for tracking. As a result, the vendors feel more pressure because if there's a delay, they know I will notice and get in touch with their superiors.

Even a small business requires project management skills and if the entrepreneur is a Project Management Professional (PMP)® he or she will rock the market.

Have you started your own business? Please share your experience.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll