http://blogs.pmi.org/blog/voices_on_project_management/ en Copyright 2010 Fri, 12 Mar 2010 16:54:52 -0500 http://www.sixapart.com/movabletype/ http://www.rssboard.org/rss-specification
As a project manager, you may feel obliged whenever you do anything for your customer. But when it comes to vendors you perhaps put yourself in a position above them and treat them differently.

Take this example:

In the IT industry we have a software engineering process group (SEPG) and software quality assurance group (SQAG) responsible for ensuring the implementation of Capability Maturity Model Integration (CMMI) processes.

Project teams follow the groups' instructions and do whatever is required to clear an audit. Once the organization clears the audit and receives a certification, no one cares about the processes anymore because of the following reasons:

1.    The project team feels unnecessary extra work was pushed on them by the SEPG/SQAG groups and the project team just wanted to be done with it.
2.    The project team feels that they are doing a favor to SEPG/SQAG by implementing the processes rolled out by them, and the SEPG/SQAG feels otherwise.

The best way to keep a sustainable process model is to mentor project teams about the importance of processes to their project. This compare to what we do with our client -- we work as a trusted advisor, providing consultation at each step.

When it comes to an internal project we start treating internal teams as a vendor and ask them to do whatever we need, it doesn't matter if it really adds any value to them. My suggestion SQAG/SEPG teams is that you shall treat the project teams as your client and act as a trusted advisor to them.

This is the only way you can have a sustainable model.]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/03/treat-me-as-a-client.html http://blogs.pmi.org/blog/voices_on_project_management/2010/03/treat-me-as-a-client.html Teams Sanjay Saini Fri, 12 Mar 2010 16:54:52 -0500 This is a guest post from Roger Chou, PgMP, of the Institute of Taiwan Project Management

Five years ago in Taiwan, there was a general lack of awareness about project management.

This led all of us in the project management community to some basic questions: How could we prove the value of professional project management teaching and qualifications to the country's leading opinion-makers? And how could we show that having as many qualified managers as possible would be good for business and therefore for society?

We decided to provide free project management training to business leaders, company managers, politicians and other influential people. All of these people knew enough about management skills and practices to take such an invitation seriously--and if it was free, how could they refuse?

In this way they would understand what all the Project Management Professional (PMP)® education providers were trying to achieve.

This became our strategy: influence the influential.

After getting first-hand experience of what it meant to be trained and to work as a professional project manager, participants started to endorse project management education and qualifications.

At the same time, we also facilitated numerous newspaper reports on major successful projects, including Taipei's Tower 101.

We also managed to get over 2,000 people--many of whom participated in the free training--to sign the petition for proper project management training sent to our main forum of elected politicians, the Legislative Yuan. Following this petition, we wrote an open letter to Taiwan's president about the importance of project management teaching and qualification.

One of the hardest places to introduce new ideas, practices, technology or anything that requires rethinking convention is within government departments. They see their main responsibility as implementing policy--discussions about or changes to working practices could be potentially costly distractions from an already sensitive process.

Despite the challenges, our efforts have paid off. As of January, all civil servants are now required to have professional project management training and qualifications.

While "influencing the influential" was a business plan specifically tailored to Taiwan's situation and needs at that time, we were nevertheless following our own professional management training.

As the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) indicates, identifying your stakeholders and satisfying their needs would be the first step to successfully managing change, regardless or how big or small that change.
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/03/changing-taiwans-project-manag.html http://blogs.pmi.org/blog/voices_on_project_management/2010/03/changing-taiwans-project-manag.html Leadership Roger Chou Tue, 09 Mar 2010 15:40:38 -0500 Is This Your Project Stakeholder? attracted a wide cross section of responses.

It made me wonder what you think of this real life experience (only the names have been changed):

Sebastian is a highly competent, upwardly mobile executive and your boss. He works 6 a.m. to 10 p.m., and is a very detailed person. He proofreads everything, making copious corrections and is also studying for his second master's degree.

You have found the best time to approach Sebastian to discuss anything is after 8 p.m. when the office is quiet and he is working on his studies. In fact, at this time of night he seems to appreciate a brief chat.

The problem is you have a "life" outside of the office and feel 8 a.m. to 6 p.m. is a very fair day's work.

How would you approach building rapport with Sebastian to allow the discussion of important project issues and enhance your career prospects without waiting until after 8 p.m.?

I will review all comments and based on your feedback I will suggest some solutions in my next post.
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/03/hey-boss-what-about-work-life.html http://blogs.pmi.org/blog/voices_on_project_management/2010/03/hey-boss-what-about-work-life.html Career Help Leadership Lynda Bourne Fri, 05 Mar 2010 11:24:39 -0500
Welcome to the wonderful world of cost estimating.

Take for instance, the original estimate for the National Ignition Facility project--it was just over US$1 billion. The final budget was US$4.2 billion. The Central Artery/Tunnel Project, also known as the "Big Dig," was originally estimated at US$2.8 billion. Through 2006, US$14.6 billion had been spent (though to be fair, this is only US$8 billion in inflation-adjusted dollars).

The original estimate for the Sydney Opera House was US$7 million. The final cost was US$102 million, more than 14 times the original estimate.

Why is estimating so tough? It's not as if estimators are dumb or poorly trained in their profession. I've earned my estimating certification, and that was one hard test--it melted my brain. I took the examination on a Friday and couldn't participate in light conversation for the following weekend.

The reason that initial cost estimates seem to so rarely align with a project's final costs has nothing to do with the work quality of the estimators. It has to do with the work quality of everybody else on the project team. You see, comparing the final costs of a project to their original estimates is a way of making the cost baseline team somehow responsible for everything that went wrong in a project.

In the case of the Sydney Opera House, bad weather, incomplete plans and drawings, and a lack of information about the material and the structure of its now-famous roof all added dramatically to the cost. The estimators didn't make those errors--other members of the project team did.

I have to laugh every time I hear a project manager lament all that's really needed is a good cost estimate--as if a sufficiently prescient estimate would work as a talisman to ward off rate variances, contingency events, poor performance and scope creep.

For those estimators who are reading this and can't believe your eyes, I figured I've spent enough ink lambasting you for hanging around projects and continually re-estimating the remaining costs as a way of providing project control capability. You deserve a break.

I'm especially interested in hearing from those estimators and project controllers who somehow find themselves the scapegoat when their original cost baseline gets blown to smithereens.  ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/03/pmbok-guide-for-the-trenches-p.html http://blogs.pmi.org/blog/voices_on_project_management/2010/03/pmbok-guide-for-the-trenches-p.html Project Failure Michael Hatfield Wed, 03 Mar 2010 13:21:57 -0500 This is a guest post from Bill Krebs, owner of Agile Dimensions LLC

The agile methodology of "scrum" is known for its 15-minute daily meetings. Its format contains three questions. Participants state what they did yesterday, what they will to today and what road blocker stands in their way.

The meetings can be deceptively powerful--if used correctly. But oftentimes they drag on for half an hour or more.

So what goes wrong? And how can you get back the benefits? Here are some ideas.

Focus

There are two kinds of work covered in a scrum meeting: Specific tasks from your project plans (or iteration backlog), and general interrupts and overhead (such as e-mail and meetings). Do team members ramble on about work that has nothing to do with their iteration backlog? Do they say a lot just to impress other teammates? 



Focus the talk on things that relate only to the tasks identified for that particular two-week block of work (an iteration). And then encourage people to focus on and finish two tasks per day. This will discourage the inefficiencies of multitasking. Team members are not limited to calling out roadblocks. They should mention any that appear. 



Have you ever heard someone who is "80 percent done" with a task every day? Each new day shows only partial progress, but never completion. Focusing on what was actually finished yesterday, and what will be finished today, helps cure this problem.

The scrum meeting is not about status. It's about completion.

Control the Number of Participants
Let the core testers and developers on the team do the talking. Other people may have an interest in the meeting, but they should just listen.

If your meeting gets bigger than nine people, hold two separate meetings and then have a "scrum of scrums" every few days where representatives from each group get together.

Go Offline
Our inner geek often wants to deep dive into architecture on the fly. (Who can resist?)

In those moments, however, the scrum master (who facilitates the meeting) should say, "That's a great topic, let's set up a time for the two of you to discuss after the meeting."

Don't leave everyone hanging while two people talk. And if you go a week without hearing your scrum master say, "take it offline," there may be room for improvement.

Remember My Three A's:
Awareness: The meeting is about knowing what your teammates are up to.



Ad: The meeting is an advertisement for collaboration. Micro teams of two to three people form, which makes for great collaboration later in the day.

Attack: Attack the blockers. The team can rally to address a problem--either within one minute in the scrum meeting, or more often, after the meeting. Problems that require detailed work by a subset of the team can be arranged for after the meeting. That way, people who are not involved don't have to sit through the discussion.



Those tips will cut the fluff--and speed up your work!
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/power-scrum-secrets-to-a-good.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/power-scrum-secrets-to-a-good.html Agile Bill Krebs Thu, 25 Feb 2010 15:46:09 -0500 Peopleware by Tom DeMarco and Timothy Lister, there's a humorous story about a project manager who--seeing the progress her team was making--knew she would deliver her project on time. With confidence, this project manager told management that she could guarantee the project would come in, as scheduled, by 1 March.

Management chewed over this unexpected good news and summoned her the next day. They told her that since she was on target for 1 March, they were moving up the deadline to 15 January.
 
I had a similar experience when I presented an initial update for a recent software project. I confidently explained to our stakeholders that the software enhancements for the common process tool would be delivered on time.

Sheepishly believing the stakeholders would be impressed, I waited for a compliment. 

Instead, the stakeholders proceeded to hand down a "schedule challenge" for the team to deliver three weeks early. Their rationale was that they wanted to capitalize on the team's productivity and wow the senior leadership team.
 
So, care to share your productivity war stories? 
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/the-danger-of-being-too-produc.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/the-danger-of-being-too-produc.html Leadership Neal Shen Mon, 22 Feb 2010 13:39:14 -0500
In order to see something great in another, you have to have some experience with that quality or talent yourself. To admire and praise a team member's dedication and value as a human being to your team, you have to know on some level what it is to feel valued and to make a contribution to a team.

When project team members show they respect and appreciate fellow team members' commitment, integrity, openness, positive attitude, expertise, knowledge sharing and listening, that's what becomes the team's--and even the organization's--core values.

When these core values are brought to light, team members listen, they don't tolerate serving their customers poorly and they have a high sense of integrity. They become what they acknowledge.

Leaders must set the example in order to have others emulate it and make it positively "rampant" in an organization. And by the definition of former Chairman and Chief Executive Officer of JP Morgan Chase, William Harrison, Jr., everyone can do this. He dramatically stated, "Be a leader. We want everybody to be a leader...to be a leader you have to have a view, be willing to constructively express it, and use it to make something better. Under that definition, everybody can be a leader."

Everyone, then, not only can be, but IS a leader. Everyone, then, can demonstrate that ability to make something better. Team leaders who focus on and make it their honor and their duty to exemplify the power of acknowledgment achieve great results. Those of us who are acknowledged find it much easier to acknowledge others.

Acknowledgments truly transform both the giver and the receiver on a project team. They engender employee loyalty and engagement, improve relationships and enhance self-worth. These positive results are contagious, and the actions of each team member are amplified as the recipient picks up on this idea and spreads the circle wider. Like pebbles in a pond, the ripples radiate farther and farther out.

You are indeed what you acknowledge! Why wait to start practicing this--as a leader, do it now and reap the rewards!  ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/you-are-what-you-acknowledge.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/you-are-what-you-acknowledge.html judy umlas Thu, 18 Feb 2010 20:00:40 -0500
Well-designed reports contain large amounts of useful information in a time series, making them a valuable data repository. And if the report covers the right questions, the process of gathering the information can generate valuable insights for the project team to act upon.

That information also allows stakeholders to extract trends and status.

And if you deliver them in person or attach a note to highlight specific issues or messages, reports can form the basis of a targeted, purposeful communication.

Some people simply like getting reports--and dropping those people off your distribution list make them more upset than you realize. This also applies to cutting content. As a rule of thumb, by the third month it's probably too late to remove sections or drop recipients without encountering some issues.

Another benefit of reports is only starting to be recognized. Jon Whitty of the University of Southern Queensland here in Australia has been measuring the emotional effect of project artifacts. Based on Jon's work it seems a well-formatted report will in itself increase positive emotions.

The project manager feels comfortable because she or he has a "proper report'' that is part of the "clothing'' every project manager wears along with their Gantt charts and other expected artifacts. And senior managers experience positive emotions because the existence of a well-presented report suggests control, order and capability.

The challenge is to design reports that are relatively easy to produce, ask the right questions, are well-structured and well-formatted, and contain needed data.

What are your experiences with reports?

(Also, I will be presenting my paper "Beyond Reporting--The Communication Strategy" at the PMI® Global Congress 2010--Asia Pacific in Melbourne from 22-24 February. It continues on a theme I've often covered here: If you're trying to influence someone, then specific and targeted communication is essential. And so is measuring the effectiveness of your message. If you are attending the congress, I hope to see you there. The best place to find me during the congress will be at the PMI Melbourne Chapter booth in the exhibition hall.) ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/the-value-of-reports.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/the-value-of-reports.html Communication Lynda Bourne Wed, 17 Feb 2010 14:42:04 -0500 PMBOK^® Guide for the Trenches, I discussed scope. Now, I'd like to cover some basic truths about schedules that project managers need to know, but won't find in A Guide to the Project Management Body of Knowledge (PMBOK^® Guide).

One vital truth that the PMBOK^© Guide is clear on is that scheduling is only one aspect of effective project management, along with scope, cost, risk, communication, procurement, human resources, quality and integration.

But you won't hear that from professional schedulers--no, no, no.

It's often believed that the central tenet of project management is the ability to resource-load a schedule baseline into one of the more robust software packages that perform critical path analysis.

This is part elitism and part what I refer to as "black box syndrome." Project team members are led to believe that if a certain software package is fed all the data it needs, then the push of a button will deliver all the management information needed to successfully complete a project.

This, of course, is hokum, but I've seen it in many a project management office.

On the other side of the coin, it's a fundamental truth that you cannot manage a schedule with a list of milestones or action items, no matter how elaborate that list may be.

What tends to happen with action item lists or databases is that they essentially turn into, , polls and polls are not legitimate management-information systems. With a poll, there's always someone who has more recent information or more complete information than what's in "the system," rendering the data there unactionable.

Note that I said the data in the system. There's a profound difference between data and information.

Legitimate management-information systems process data into information using some kind of methodology. For schedules, this method is critical path. And it's a safe conclusion that there is no legitimate schedule management without critical path.

For serious project work, a critical path network is absolutely essential. This no doubt contributes to the phenomenon of schedulers thinking critical path management is all that is essential in project management, with the other stuff kind of ancillary.

I'm looking forward to everyone's comments. ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/a-pmbok-guide-for-the-trenches-1.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/a-pmbok-guide-for-the-trenches-1.html Michael Hatfield Mon, 15 Feb 2010 13:28:56 -0500 previous post, I talked about work commitments. Sometimes success in project delivery requires breaking those commitments if they are not in line with your goals. If you need to break a commitment, I recommend the following steps:

1.    Identify a commitment you have made that is not benefiting the project.

2.    Consult with the project manager and/or supervisor whether this activity can be removed from your list.

3.    Identify someone suitable to deal with this task. Seek advice from your manager when in doubt.

4.    Once you've secured management authorization, transfer the details of your commitment to that person.

5.    Advise the person to whom you originally made the commitment that the task has been reassigned to another person, and explain the reason for this action.

Depending on your role and authority, you may be able to deal directly with the person to whom you made the commitment, and you can resolve the conflict without involving other parties.

There's no magic formula for undoing what's done. But by breaking such commitments in this professional manner, you are renegotiating the terms of your commitments and earning trust and credibility.  ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/breaking-your-commitments.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/breaking-your-commitments.html Career Help Dmitri Ivanenko Thu, 04 Feb 2010 15:12:06 -0500 3 Idiots. The moral was to follow your passion--which got me thinking...

In the software industry I've seen examples of technical leads who were promoted to project manager based on the assumption that they'll perform just as well in that role.

But in several of these cases the technical lead has failed in the new position. That's because project management is not about resolving technical issues. It has other parts: resource management, cost management, expectation management, etc.

Companies shouldn't automatically follow the standard growth path for each role, whether it's for a software engineer, senior software engineer, technical lead or project manager. Rather, the path should be decided based upon an individual's capability and interests. A technical lead may be interested in business analyst work or quality-assurance activities instead of the project management role.

Also, as individuals we should have the opportunity to follow our passion and not feel tied to a typical career path.

What do you suggest?
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/02/veering-from-the-typical-caree.html http://blogs.pmi.org/blog/voices_on_project_management/2010/02/veering-from-the-typical-caree.html Career Help Sanjay Saini Wed, 03 Feb 2010 16:59:55 -0500 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.
]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/01/is-this-your-project-stakehold-1.html http://blogs.pmi.org/blog/voices_on_project_management/2010/01/is-this-your-project-stakehold-1.html Leadership Risk Management Lynda Bourne Fri, 29 Jan 2010 10:10:50 -0500 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. ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/01/a-pmbok-guide-for-the-trenches.html http://blogs.pmi.org/blog/voices_on_project_management/2010/01/a-pmbok-guide-for-the-trenches.html Michael Hatfield Thu, 21 Jan 2010 13:08:42 -0500
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! ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/01/project-lessons-from-parenthoo.html http://blogs.pmi.org/blog/voices_on_project_management/2010/01/project-lessons-from-parenthoo.html Neal Shen Wed, 20 Jan 2010 11:20:58 -0500
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.  ]]> http://blogs.pmi.org/blog/voices_on_project_management/2010/01/pick-your-commitments.html http://blogs.pmi.org/blog/voices_on_project_management/2010/01/pick-your-commitments.html Dmitri Ivanenko Mon, 18 Jan 2010 19:02:32 -0500