Project Management Training and Consulting
Best Practices. Best Delivery. Best Value

project management questions and answersSend your questions and comments
about project management to Projects@VersatileCompany.com.

Finding Unknown Stakeholders

What is the best way to identify unknown stakeholders that have influence?  - S.D., Wisconsin

A good question.  Everybody knows we're supposed to manage stakeholders, but how are we supposed to manage the unknown ones?  Several years ago I presented a paper at PMI Congress addressing this very issue.  As my friend Steve Giesen would say, stakeholder management is "Risk Management for People."  My stakeholder management process mirrors my risk management process:  1. Identify the Stakeholders.  2. Assess their interest and influence.  3. Respond accordingly.

What about the original question?  "How do we manage the unknown risks?"  Stakeholder identification processes can be just as disciplined as risk identification.  Use the same techniques: brainstorm with the team, use a risk profile. If you haven't seen a "risk profile" for stakeholders, look at the downloadable stakeholder assessment for the Fast Forward MBA in Project Management (chapter 5).

Criticial Chain Project Management

What do you think of critical chain project management? E.D., Columbia

Critical chain is a great example of innovative thinking. By applying classic manufacturing management ideas to projects, critical chain provides new insights for compressing schedules.

First, a quick explanation of the term 'critical chain'.  Critical path is a well known method of identifying the sequence of tasks that have the longest duration, and therefore dictate the duration of the project.  (If this is new to you, see my book, The Fast Forward MBA in Project Management, chapter 7.)  Critical chain recognizes that we must also take into account the resource constraints that limit how much work can be performed concurrently.  So the 'critical chain' are the resources that dictate the overall schedule duration.

A fundamental introduction to critical chain (and a fun read) is Dr. Eliyahu M. Goldratt's book, The Goal. 

Can MS Project Help Manage Cash Flow Over Multiple Projects?

Can Microsoft Project help me track expenses against individual projects when I've got the same people spread across multiple projects? My current tracking system just shows the monthly cost of the resource.  -- T.S.,  Ontario

This is a classic example of the difference between project accounting and traditional accounting.  And yes, Project can do this pretty easily. 

Projects typically need to track the cost of accomplishing specific goals and when the cost was incurred. Traditional accounting just captures when a cost was incurred.

There are several strategies for keeping track of resources that are spread across multiple projects when using Microsoft Project. Fortunately, Sam Huffman has good examples for two of them on his blog this month.  Read Sam's Microsoft Project blog here. Other strategies are presented in Versatile's Microsoft Project 2010 Online Boot Camp.

Judging A Project's Financial Success

How important is the financial factor for judging project success? - Y.F., Jordan

Every project has an important financial goal. But don't confuse financial success with completing on budget. 

 

Even non-profit organizations set financial goals for projects. Financial success is a combination of two factors: expenses and results.

 

Expenses are typically the focus of the project manager.  When we want our project to be "on budget" we are focused on the expenses.  Goals for financial results are set when the project is initiated.  For example, cost savings or increased revenue or market share. Too often, the project manager is not involved in setting these goals and therefore is not particularly focused on achieving them.  That's tragic, because the purpose of the project is to achieve results, not to minimize the cost of the project. The other common failure is to not measure results, because the project is accomplished and the team disbanded before the results start to materialize. 

 

The project is initiated based upon forecasts of both expenses and results. The irony may be that the project manager has the biggest focus on cost, while the results have the greatest potential to make a big impact.  A project ought to be managed to generate the greatest value - which makes measuring results essential!

    Thesdaf   dkdk

When the PM is Also a Team Member

When resources are limited, how much should the PM take on? - L.D., Arizona

There's nothing that says a project manager can't pick up a shovel, test some code, or work side by side with the team on any tasks.  In fact, for many industries it is more common to be a project manager AND a team member. 

The real issue is whether attending to project tasks gets in the way of managing the project. 

Many of us - including me - manage the work and do the work.  We wear two hats (and often a lot more than two), so it's really a balancing problem. And the problem is associated with balancing important work vs. urgent work.  The project tasks are both more tangible and more urgent than project manager activities. So we can get caught up in meeting task deadlines and neglect our project leadership duties.

If your project is small enough that it is not a full time job to manage it, then it makes sense to pitch in and play the role of team member as well.  But structure your daily and weekly calendar so that you are regularly devoting time to the job that only you are doing: project management.

 

Distinguish between small and large projects

You've talked about managing small projects differently than large projects.  How do you determine whether a project is small or large?  - H.E., Washington

Distinguishing between large and small (and medium sized) projects goes along with establishing standard project deliverables.  We make the distinction in size as a way to adjust the expectations about how much time should be spent managing the project.

The easy answer is to use cost as a size differentiator.  Cost – whether in pure dollars or in labor hours – is the most common way to categorize projects. That makes a lot of sense, since it is objective data that is known at the time of project initiation. But a more complete answer includes assessing some other factors to rate the overall complexity.

In addition to cost, total duration of a project and team size are other factors that affect project size.  These two factors usually increase the cost of a project, so in most cases cost can continue to be the only factor for project size.

The other factors to consider, though, are technical challenge (risk) and the number of stakeholders involved.  Stakeholder diversity increases the amount of communication and coordination.  Since most project management tools address communication or coordination, having many stakeholders justifies using the full set of project management tools even on a low-cost project. 

Experience and Estimating Projects

When estimating a project what is the relative importance of direct experience for different parts of the team?  e.g., how much does it matter if the PM has managed a project with similar technology?  How much does it matter if the developers have worked within a specific methodology before? – J.A., Washington, DC

Direct experience by the project manager and the team is a significant driver for estimating accuracy on software projects.  Keep in mind that estimating is not just a math problem – plugging some variables into a formula to generate effort or duration.  That is even more true for a software development project. 

The art of estimating assumes that the leader and/or the team has a clear vision on how they’ll build the product.  On the other hand, the whole team doesn’t need direct experience.  Realistically, one person with a strong understanding of the scope and the development process can visualize the path forward and use that vision to generate an estimate.  Lack of direct experience within the team is a negative productivity factor, and estimating the learning curve has its own challenges.

Here’s another way to look at this.  150 years ago the wagon trains rolling across the American West typically had only one person that actually knew the route.  Each train would hire a guide that knew the terrain and had experience with the journey.  A party that lacked that one key person could easily perish due to any one of dozens of threats along the trail.  But with one person that knew the way, the basic strengths of the other travelers were enough to get at least most of the group to their destination.

I’ve said it before and it is worth repeating here: Project management is not industry specific, but the same cannot be said for project managers. The technical expertise required to estimate projects and lead technical decision making is difficult to replace.  A strong leader with good technical team members can pull it off, but even that combination is risky.

Consensus Paralysis

"How can I converge conflict asap? Since team meeting time is limited, if we spend too much time to listen and resolve the conflict to reach the consensus, we can't cover all topics. We can't offline every topic." J.F. California 
Conflict is a good news/bad news situation.  It's good that your team is willing to hash things out, but as you point out, reaching consensus on every item is draining.  Some tactics you might try:
  • Let the boss decide.  Seriously. Not every decision is a team decision. Break your consensus paralysis by acknowledging that either the boss or the subject matter experts can make the decision. If It is appropriate to get input from the team members use active listening to assure everyone that their ideas are understood.
  • Strong facilitation. Go around the table one time and let everyone make their contribution.  Then synthesize what you heard and turn that into the proposed consensus and finish with, "can we all live with that?"  Consensus is a process, not unanimous agreement.
  • Frame the problem correctly. Long winded discussions are often a symptom that it isn't clear what decision is being made. Frame the decision being made and be willing to bring people back on track if they head off on tangents.
Facilitation is a skill.  Good meeting leaders are skilled at framing the issue and creating balanced, focused discussion and bringing it to a resolution. It is a skill that can be taught, learned, and practiced.