Analysis for Project Completion Date

Here's nice application of Monte Carlo techniques for estimating the project schedule completion date. ...

... "To use the Monte Carlo analysis, instead of just one estimate of duration for an activity, we create three. First, we estimate the most likely duration, and then we estimate the worst case and the best case. " ...

Via TechRepublic: Use Monte Carlo analysis for projects

Perform to Schedule

Performance to schedule is critical to manufacturing processes. This same discipline needs to extend to project schedules. However, not all projects and tasks are as repeatable as manufacturing steps. And, people aren't machines. ...

... "At the manufacturing level, processes are expected to be adhered to with clockwork precision to meet defined deadlines. With over 6 lakh cars a year from three assembly lines in Gurgaon and 1 lakh from a plant in Manesar, the shop floors need to produce exactly to a plan. " ...

Via InfoWorld Nederland: IT on wheels

Project Forecasting: More Lessons from Driving

A while ago, I entered a post about the importance of staying tuned in, drawing an analogy to driving. Well, another driving analogy had occured to me, this time about the need to focus on remaining time.

Let's put it this way. If you're driving from Philadelphia to New York City and you're at the entrance to the New Jersey Turnpike, what percent complete are you on your trip?

Some of you may guess certain percentages based on distance, but that's as foolish as basing project percent complete on the percent of budget or time that's been spent, without regard for work accomplished.

The quick answer is: Who cares what percent complete we are? What we really should be concerned with is how much time is left, assuming we care about what time we arrive to begin with.

But let's say that we DO care (i.e. schedule is a priority for us, as opposed to some other success factor). How can we measure whether we'll be there on time?

Simply using a percent complete tells us nothing. It's too subjective. What we need to know how much time is remaining. And that will depend on how fast you're going, how many miles are left, what barriers may arise (i.e. road closings, flat tires, etc.), how many stops you make, and a number of other variables. It's no different for projects.

For project schedule control, capturing percent complete is too theoretical, so that's not of much use to us. And capturing time spent tells us very little, except perhaps how long it took us to do prior work, which may not be an accurate indicator of future work. Besides, we can probably determine future work estimates more accurately through expert opinion and/or statistical sampling (combined with good planning).

Of course, there's no harm in entering time spent as long as people are disciplined to always include time remaining. Then a percent-complete can be calculated based on that. But the percent-complete itself is not a leading indicator, so is still of questionable value.

If we focus instead on time remaining at the task level, and combine that with barrier removal, risk planning, and regular reforecasts, we'd have much better control over whether we "arrive on time."

We can improve our ability to estimate in the future by capturing lessons learned, doing spot checks, and using the information to create project schedule templates and checklists, so future projects can avoid running over the same potholes.

Some may say, "Oh, we still need the percent-complete for Earned Value calculations."

Do we really? By putting a dollar amount to the time remaining, we can solve the same problem in a simpler fashion, answering the question: How much is it going to cost us to complete this project and what's our estimated time to arrival?

Just some food for thought. See my followup post on Project Forecasting and Uncertainty as well.

The Five-Minute Project Manager

Sometimes the best project management tips come from other fields, such as this free "Five Minute Guide to Project Management" from a creative arts website.

Simple, to-the-point, and yet quite effective, this brief guide reminds us of the basics that so often get forgotten in the midst of earned value, critical path, and other favorite topics of PM nerds.

As the article discusses creating a project plan and formally managing subsequent revisions as part of a "contract" between you and the sponsor, let's not forget the importance of defending the right plan.

I was having lunch with a group of CIOs the other day (following a presentation I had done), and all agreed that the number one killer of projects was an unrealistic plan, often agreed to under duress by an intimidated project manager.

Several CIOs present shared success stories of making a case to other senior executives by way of a high level project schedule, outlining the steps needed to achieve results. Often, that's all it takes. Some people I've spoken with have had some luck backwards-scheduling as needed from a given target, either to demonstrate the futility of the desired target, or to raise discussion as to which items can be eliminated.

Anyway, I digress. Here's the article about the PM basics ...

creativepro.com - The Art of Business: Project Management for Creative Professionals

Results Project Failure Poll

Communications, resource planning, and scheduling were identified as top root causes of project failures in CompTIA poll. ...

... "Nearly 28 percent of the more than 1,000 respondents to the web poll singled out poor communications as the number one cause of project failure. Insufficient resource planning was the second most mentioned cause of project failure, cited by just less than 18 percent of poll respondents. The third most frequent cause of project failure, according to the CompTIA web poll, was an unrealistic schedule, chosen by 13.2 percent of poll participants. " ...

Via CompTIA: Project Failure - Root Cause Poll ...

Project Execution

Tom Peters and crew on strategy implementation through execution ... here's a chance for the project manager to shine ... Get the leadership support. Break the plan into chunks. Schedule the first chunk and resource the team. Start driving. ... Sounds simple. ...

... "Great execution happens in small manageable chunks by taking large plans and breaking them into manageable parts. Otherwise, the path to execution can seem so overwhelming, people can't conjure up the energy. " ...

Via tompeters!: Execution through Projects

Impossible Project Becomes Possible

Remediation project of Rocky Flats contaminated nuclear weapons facility demonstrates that the impossible can be accomplished. ...

... "Now on its way to becoming a wildlife refuge, the project is running 60 years ahead of schedule and $30 billion under budget. " ...

Via Line56: KM Blog: Link

IT Project Dashboard

Anecdote on IT project performance with mention of top 5 root causes. Chevron referenced for its management practices that focus attention on the highest value projects in its portfolio. ...

... "According to Accenture, the average IT project exceeds its projected cost and schedule by 56 percent and 84 percent, respectively. " ...

Via ITBusiness Edge: Link

Earned Value Lies and Truths

There was a great quote from Benjamin Disraeli in David Hillson's letter to the editor in the latest PM Network Magazine.

Disraeli allegedly* said, "There are three kinds of lies: lies, damn lies, and statistics."

* As an aside, there's apparently some debate over the actual origin of this phrase.

In any case, Hillson's interesting letter was cautioning those who frequently misapply statistics, and offered some clarification the terminology----specifically, the mean (average), mode (most frequently occuring item), and median (the middle item if all were lined up in order).

I find that many misuse Earned Value statistics the same way. The intent of EVM is to be an early indicator of a potential cost or schedule overrun (and I personally feel that it's better at predicting cost than schedule). However, much like the Ghost of Christmas Future, it's not set in stone. There are many things a project manager can do to get things back in order. More importantly, sometimes there are reasons for the apparent variance that indicate that the variance is explainable and not a concern at all.

The key with EVM (much like any metric) is to not take the statistics at face value, and to use them as a trigger to do further subjective examination. It's a tool, and organizations often overuse such tools (much like they do with Six Sigma). If all you have is a hammer, everything looks like a nail.

Yogi Berra on Project Management

There's a cute article in Computerworld called Yogi Berra, PMP. The article uses the baseball great's famous quips to make some compelling points about managing projects.

Of course, it didn't include one of my favorites as it applies to project management. When someone said to Yogi, "Hey Yogi, I think we're lost," he replied, "Yeah, but we're making great time!"

Unfortunately, this happens all the time in project management. Many methodologies focus on schedule, budget, and execution----and fall short when it comes to defining the problem and goals (and aligning them with the organization's needs). As a result, we end up getting to the wrong place fast.

Here are some other fun Yogi quotations, and here's the Computerworld article...

Yogi Berra, PMP

Project Gates: Are Kill Points Really Considered?

Since capital is usually constrained in most organizations, are we really making the best use of our project stage-gates as potential kill-points? Are we fully considering the cost-to-completion, the probability of realizing the original benefits documented in the business case, or a declining ROI if costs escalate? We will be doing a service to our organization if we take some time to develop exit criteria and consider alternatives at the project stage-gates. There's always another project in the portfolio. ...

... "The Project Plan should have included a schedule for steering committee meetings and other key points to ensure regular tracking of project progress and release of status reports. Additionally, the plan should have identified milestones and project kill points, that is, go/no go decision points for the action of senior management, the steering committee or other authority. " ...

Queensland University: Controlling phase

Project Risk Management

Oil production company, Venture Production PLC, uses risk management software to model project scenarios to select optimum schedule while balancing risks, costs, and time performance. This seems a worthwhile approach, when large investment is at stake and time to value is critical. ...

... "Using Pertmaster, Venture's project management team was able to add a risk dimension to plans built in its Primavera P3 scheduling solution. Venture then analysed the schedule-risk of multiple scenario options to look at the most probable outcomes of each, in terms of both timescales and costs. This enabled the best options to be highlighted when considered from both likelihood of risk occurrence and degree of impact and enabled management to take well-informed decisions. " ...

Pertmaster Helps Bring Venture's New Oil Field On Stream ...

Venture Operated Goosander Field On Stream: "Goosander has been developed as a sub-sea tieback to the Venture operated Kittiwake platform utilising two subsea flowline bundles totalling 12 kilometres in length. The bundles were manufactured and installed by Subsea7 from their construction site in Wick and have been designed and engineered to accommodate future production and water injection wells and the potential for re-use on future subsea tie-backs. "

Project Management Graphics: Lessons from Edward Tufte

I recently checked an old discussion thread on project management graphics that I had participated in on Edward Tufte's forum. Suprisingly (or perhaps not), the thread is still going strong after four years! It must be the world's longest running discussion thread.

The premise of the thread was to find other ways of portraying project status and schedule beyond the Gantt chart. Edward Tufte, for those not familiar, is the world's leading guru on information presentation.

He was brought in by NASA after both the Challenger and Columbia disasters to analyze why the scientists weren't able to present the facts in an effective enough way to avert the disasters.

Tufte is listed as one of Amazon.com's top 100 nonfiction authors of all time.

For those interested in breaking new ground in project visuals, it's worth checking out. Feel free to participate.

Ask E.T.: Project Management Graphics (or Gantt Charts)

Einstein Project Management Tip #4: Think Value

And so we continue our series on project management tips from Albert Einstein. Here's another...

"Strive not to be a success, but rather to be of value."

This sums up perfectly the problem with most projects today. They focus on "success" without fully defining what success means. Project managers and PMOs track schedule and budget metrics. Then, at the end of the project, some capture customer satisfaction, almost as an afterthought.

What really needs to happen is to insure value to the customer, and this usually goes way beyond being on time and on budget. We spoke about the need for clear goals. Surely that's part of it. We also need to deliver in small, frequent iterations to provide the quickest value and get more immediate customer feedback.

Customer satisfaction should be measured and tagged as an index throughout the life of a project, just as Earned Value uses indices to track cost and schedule performance. This allows course correction to be made in areas such as goal clarification, communication, and other areas needed to provide good value.

And when the product has been delivered, be sure that the customer can maximize the benefits of the product through proper training, tips & techniques, next steps, or any other items that will help them get the value expected.

These are the very items I've attempted to address with my Service-Oriented Project Management (SOPM) framework, with its four phases of Understand, Prepare, Iterate, and Transform (UP-IT).

More Einstein tips coming soon...

Talent and Project Management

I received the latest PM Network magazine from PMI the other day, and several things jumped out at me, especially following my last blog post on the winds of project management changing.

First, Neal Whitten had a great article about how a project analyst (what I've often called a "project control specialist") can be a valuable aid to a project manager by taking on the responsibilities of: project tools management, plan development, sub-plan collection, project support, supporting project tracking meetings, filling in for the project manager at times, and other areas that can free a project manager up to actually lead the project.

It got me thinking about the talents needed for the project manager role, the project analyst/specialist role, and any other roles needed on the project. But more than that, it got me thinking about talent management in general, and what it means to the project management industry.

Just look at these headlines, all from this month's issue:

• Attracting--and Keeping--top talent
• Executive Identity: Project managers should learn to think like executives
• A People Person: Succeeding in project management---and getting what you need from thise around you---requires a well-honed set of people skills
• Virtual Reality: Dispersed project teams are sparking shifts in management and leadership styles

Clearly, the talents needed to manage projects go way beyond schedule, budget, and cost control. Notice I said "talents" as opposed to skills or knowledge. As Marcus Buckingham points out in his excellent book, First Break All the Rules, there is a huge difference between skills, knowledge, and talent. The first two can be taught. The last one--talent--is innate, and cannot be taught.

This becomes clear when you apply Buckingham's definition of talent as "ANY recurring patterns of behavior that can be productively applied." Everyone has talent. It's just a matter of discovering it and matching them to the right role. The key point is that a person's nature cannot change that much, so it's important to select someone with the right talents (i.e. innate traits). Once that's done, you need to set clear expectations, motivate the person (through praise and recognition of their strengths), and ultimately develop the person (building on the strengths that already exist instead of fruitlessly trying to fix weaknesses).

So what does this mean to the project management field? Everything. It means we need to begin thinking about these innate talents when we hire and assign project managers, when we staff the project, and when we consider how to motivate the team. The talents needed for each role will be different. And, based on the nature of the project and the stakeholders involved, the talent required to manage each project may be different. There is no "one size fits all" when it comes to talent selection.

It's not that skills and knowledge aren't important, but these two items without the correct talents will not bring about success.

What I like about Buckingham's book is that it's based on facts---years of research with the Gallup organization. Anyone who selects and manages people should read this book. And when you do, think about the diverse talents needed for each person on your team, and for the project manager role for each individual project.

Project Management Winds Are Changing

There's an excellent article by Betsy Morris in the current issue of Fortune Magazine about how the Jack Welch way of winning is---dare we say---a thing of the past.

How is this relevant to the project management field? Well, for one, it means recognizing the winds of change in the industry, and how projects are selected, promoted, and managed. Above all, this impacts program and portfolio management. Particularly, note four trends in management thinking:

Innovation:

Let's take Welch's old rule of being number 1 or 2 in your market (or else fixing, selling, or closing the business). The new rule is to find a niche and create something new. The article uses CocaCola as an example of a company that was basking in their glory as number 1, but eventually realized (although it took a while) that energy drinks and bottled water were about to pass them. As the article points out, energy drinks "are now expected to outearn every other category of soft drink within three years." Parhaps marketing guru Harry Beckwith said it best in Selling the Invisible when he said that it's fine to do something 10% better until someone else comes along and does it 110% different.

Customer-Centric Management:

Welch started a whole movement of focus on the shareholder, which led many organizations to ignore the future amid pressure to appease shareholders and "make the numbers." Now, organizations realize that the customer is king. The article references several companies that have made this realization, and the trend is heading in that direction. After all, statistics show that even a minor improvement in customer retention leads to a major increase in profitability. The days of short-term thinking may be finally coming to an end.

Reinvention vs. Incremental Change:

Since it seemed Jack Welch could do no wrong, everyone imitated whatever Jack did---and Six Sigma was no exception. The problem is that, according to the article, of the 58 large companies that announced Six Sigma programs, 91% have trailed the S&P 500 since. As the article points out, that's mostly because Six Sigma is intended to "fix an existing process," whereas innovative companies that developed new and unique products (or reinvented their business) took the lead.

Stop Ranking Your Players; Inspire Passion:

Once of Welch's most controversial systems was to constantly rank his employees and regularly weed out the "C" players. But companies have had difficulty getting productivity and innovation out of "increasingly disenfranchised employees." In the article, Christopher Bartlett of Harvard Business School put it best:

"People don't come to work to be No. 1 or No. 2 or to get a 20% net return on assets. They want a sense of purpose. They come to work to get meaning from their lives."

Side editorial: For the "enlightened" approach of finding the hidden strength in everyone (something Peter Drucker always suggested), read Marcus Buckingham's Now Discover Your Strengths (or any of his books for that matter). Or read Dennis Littky's The Big Picture: Education is Everyone's Business. I assure you, you'll never be the same.

Meanwhile, I highly recommend the article (the link is below) for those looking for the latest trends in management thinking, and who want to remain one step ahead.

From a project management perspective, the handwriting is clearly on the wall. The traditional "execute to a set of deliverables" approach won't cut it. Today's project manager needs to be thinking about things like innovation, customer focus, business transformation, business acumen, change leadership, and team passion. Those focused on merely schedule, budget, and scope will soon be dinosaurs.

Fortune: The new rules - Jul. 11, 2006

The Distributed PMO: Lessons From Strange Places

I've read two pieces of information lately that couldn't be more different, and yet they both got me thinking about the benefits of what I call a "distributed PMO."

First, as I mentioned last week, I had read about Ken Kizer's magnificent transformation of the formerly abysmal Veteran's Health Administration (a poorly run group of hospitals mired in government hierarchy and bureaucracy). He established an network of regional "hubs" (what he called Virtual Integrated Services Networks, or VISNs - pronounced "visions"). Each VISN was itself a network of partnerships, associations, alliances, hospitals, etc. that worked together for the good of the customer.

The VISNs had the benefits of standardized quality with local presence. Decision-making was moved from Washington HQ to the VISNs, who were closer to the action than Washington HQ could ever be.

The role of headquarters became one of support, guiding principles, consulting advise, information services, and change leadership. Headquarters drives behaviors that benefit the overall structure.

Forms and approvals were reduced to a bare minimum. A relentless focus on the customer/patient (one of my battle cries, as most of you know) now guides all decisions and research.

If this isn't a good model for a PMO, I don't know what is. If project managers and functional experts (each who rely on one another for success) operated in various "regions" and/or functions (close to the action), and the PMO's role were to provide (and I repeat from above) support, guiding principles, consulting advise, information services, and change leadership, more PMOs would become a valued and integrated part of their organization.

And if the focus were on reducing forms and bureaucracy, helping project teams be successful, and improving the customer experience (as opposed to an internal focus on merely schedule and budget metrics), PMOs might find themselves more popular as well.

Incidentally, this also happens to mirror the Toyota organizational model.

The idea of a distributed, integrated network isn't unique to business. It even happens in nature (here's where the strange part comes in). I was reading about a giant sea creature, larger than a blue whale, called a Giant Siphonophore (Praya sp.). The creature (yes, this is true, folks) runs 130 feet long and is actually made up of many other life forms, each having its own specialized role that works to service the whole entity, yet is unable to exist on its own. In other words, the Giant Siphonophore is a "colonial life form." As I read this, I was again reminded of the concept of a virtual, yet integrated network.

Yes, I actually make these odd connections, but ideas can come from anywhere. By the way, the creature can be seen in the IMAX film, The Living Sea (available on DVD). Here's more info on the colonial nature of the Giant Siphonophore and it mutually dependent parts. Food for thought.

Is the Role of the Project Manager in Jeopardy? - An Editorial

A few weeks ago, I posted a blog about the new Program Management credential from PMI. In it, I referenced PMI's definition of a program manager vs. project manager in their FAQ page.

A project manager, according to PMI, has the following responsibilities (I've put some of the key points that jumped out at me in bold):

• Perform their duties under general supervision and are responsible for all aspects of the project for the life of the project
• Lead and direct cross-functional teams to deliver projects within the constraints of schedule, budget and resources
• Demonstrate sufficient knowledge and experience to appropriately apply a methodology to projects that have reasonably well-defined project requirements and deliverables.

A program manager, according to PMI, has the following responsibilities (again, I've bolded the key points):

Under minimal supervision, program managers are responsible and accountable for the coordinated management of multiple related projects directed toward strategic business and other organizational objectives. These programs contain complex activities that may span functions, organizations, geographic regions, and cultures. Program managers build credibility, establish rapport, and maintain communication with stakeholders at multiple levels, including those external to the organization.

Clearly, a program manager must be closely tied to the strategic goals and benefits, monitor the program accordingly, and have a strong connection to senior management. And I also feel that the new credential seems on the surface to set the bar appropriately high.

But I can't help but feel that, in contrast, the PMP credential is losing steam. First, there are myriad organizations virtually guaranteeing an "instant-PMP" after a crash course and some tweaking of one's background experience (although PMI is now doing audits of work experience).

Second, a project manager must, in many cases, go beyond the PMP/tactical focus and possess the same traits and skills that PMI has designated as requirements of a program manager, especially in the case of an enterprise and/or global project, such as a business transformation effort. I realize PMI's role definitions are a way to differentiate and justify the new certification and I suppose one could organize their effort into a "program" to qualify for that certtification, but in these changing times (and with greater challenges for project managers), I think PMI needs to evaluate and revamp the PMP certification as well.

When I do presentations on principle-based leadership training, I have a slide where I present what I call "The PM Challenge." I present it as a boxing match. In one corner, we have a project manager, armed with MS/Project and the PMBOK, but lacking:

• Business Acumen
• Leadership Skills
• Conflict Management Skills
• Negotiation Skills
• Presentation Skills
• Communication Skills
• Strategic Intuition

In the other corner, we have the "challenger," represented by "the project," with the following characteristics:

• Global, virtual team
• Complex technology
• Complex change
• Multiple vendors
• Offshore resources
• Conflicting Stakeholders
• Scrutinizing Executives

Such a project manager, without the appropriate leadership and soft skills, doesn't stand a chance. Wouldn't a person with the skills PMI describes as a "program manager" be more apt to have success?

In the latest PM Network magazine from PMI, there are not one, but TWO articles that illustrate this point. One is titled "Project Management 2.0: Project Management is at a Crossroads," by Peter Fretty. The other is titled "No Limits," by Marcia Jedd, and talks about what project managers must do to crash through the glass ceiling and elevate it from the tactical trenches.

Perhaps a start would be to take a new view of project management beyond just "executing to a set of requirements to deliver on-time and on-budget." The current tactical focus might explain the consistent failure rates of projects. One problem is that PMI has traditionally "followed common good practices in the field," which of course is what a standard is supposed to do. The problem is that common practices have brought common results, which aren't all that good. Time for an upheaval. Perhaps they need a section, apart from the "standard" itself, for "new frontiers in project management," which could outline those who are breaking the mold with good results.

I'd be interested in others' thoughts on this topic. Who knows---It just might help drive requirements for the next version of the PMBOK and/or PMP credential.

PMO Success Story: A.G. Edwards Case Study

There's an excellent article in CIO Magazine this month showing how A.G. Edwards reinvented its PMO to bring their projects to an 88% success rate (from about 50% originally).

Some key lessons:

• They created a 25-step project management high-level framework of just the high level activities common to all projects. They didn't inflict a detailed application development methodology and left the "how" flexible, as long as the "what" was satisfied. At a more detailed level, they used Primavera for project tracking and dashboard metrics.
  
• They provided leadership training to boost the confidence of their PMs
  
• They moved the project managers from the PMO to the functional areas to encourage collaboration and better align the PMs with the business.
  
• They offered project planning services to assist the distributed project managers with using the new framework effectively (allowing them to use the planning tool of their choice, be it Excel, MS/Word, or a whiteboard). The 25 framework touchpoints, however, are common to all projects for cross-project comparison purposes (I assume enabled in Primavera).
  
• They redefined "success" as "projects that deliver business value." This gives customer satisfaction and business value even greater priority than being on-time and on-budget (note: they still improved their schedule and budget statistics anyway).
  
  This is the essence of the new model and bears repeating. The customer defines success. Under this model, it's quite possible to have a project that is late and over-budget and seen as a raving sucess.
  
• They tirelessly met with stakeholders in individual and group settings to offer the benefits and ask for their support. They used a subtle soft-sell approach with the "bad actors."
  
• They first involved the PMs receptive to new ideas as part of a pilot and them used them to "spread the gospel"
  
• They measured success rates and publicized them in quarterly reports to senior management.

These are all powerful and valid ways to make a PMO successful, and are philosophically aligned with the Service Oriented-Project Management (SOPM) model I've been developing. In this case, these changes collectively served to boost IT's credibility at A.G Edwards significantly.

Here's the full article. Don't miss the sidebar "8 Steps for Improving Project Management."

When Failure Is Not an Option - Editorial - CIO

SOPM; A New Project Management Methodology

Service Oriented Project Management (SOPM) is taking shape as a methodology that fills the gaps in traditional project management, namely a RELENTLESS customer focus and the all-important analysis and benefits evaluation after the project has "completed."

As I fine tune the model, I'll post the iterations here, as a methodology in progress.

The four high-level steps in SOPM are as follows:

1) UNDERSTAND ... Develop an understanding of the problem being addressed, the goals, constraints, the internal environment, the external market, benchmarks, the people and subject matter involved, potential solutions, risks, benefits/justification, and any other knowledge necessary for success. Most of all, understand the customer.

2) ENABLE ... After helping the customer obtain approvals, prepare the project organization (resources, roles & responsibilities), operating principles, the infrastructure and tools needed to run the project, organizational alignment, preliminary training needed, communication, and anything else needed for a smooth road ahead.

3) ITERATE... Plan, design, build, test and pilot the solution before attempting a full scale implementation. Implement in phases to achieve quick wins, earlier benefits, and greater customer satisfaction. Consider iterative prototypes during the design phase. Don't forget additional training needed.

4) EVALUATE... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected). This includes evaluating how the customer can achieve maximum results with the product of the project, and laying the groundwork for their continued success.

By using an UNDERSTAND, ENABLE, ITERATE, and EVALUATE process, with COMMUNICATE as an overarching activity that extends across all four steps, we adopt a much more holistic and customer-centered approach to project management.

A few key points... Customer satisfaction should be measured at milestones throughout the project, not just at the end. It's as important as monitoring cost and schedule (i.e. Earned Value performance).

Imagine seeing an S-Curve showing Planned Value, Earned Value, Actual Cost, and Customer Satisfaction. Maybe your project is on schedule and on budget, but the customer isn't satisfied with the results (or with the project communication, or a whole host of other issues).

A narrow focus on cost and schedule takes too much of an inward view. Besides, measuring customer satisfaction throughout a project allows for corrective action instead of managing in the rear view mirror.

More to come.

NOTE: I have since revised this model. See my updated entry.

Project Failure Case Study; Maine's Medicaid System

Talk about a project disaster. As reported in an excellent article in CIO Magazine, the Maine Medicaid Claims System project is a case study of a project gone awry.

The project was undertaken to switch from their legacy systems to a new web-based system to process Medicaid claims and facilitate HIPAA compliance (Health Insurance Portability and Accountability Act of 1996). As a result of the failed project, Maine is now the only state in the union not in compliance with HIPAA.

System problems led to many claims ending up in limbo, leading to hundreds of calls from health care practitioners, nearly 300,000 patients being turned away, several dentists and therapists going out of business, and destroying Maine’s finances and credit rating.

So what went wrong?

Mistakes included the following:

• Deciding to develop an entire system from scratch using unproven technology, while other states built a front-end onto their legacy systems
• Caving to pressure from management to meet tight deadlines with inadequate resources instead of pushing for a realistic plan to begin with
• Failing to notice why other bidders either didn’t bid or came in way higher (a sign that the schedule was unrealistic)
• Hiring a vendor with no experience in developing Medicaid claims systems because they were the lowest bidder
• Not having a Medicaid expert on the team, leading to errors in judgment
• Underestimating the time needed to meet with subject matter experts
• Competing with another major initiative (a department merger) for executives’ attention and resources
• Skipping project management basics (including piloting, adequate end-to-end testing, staff and user training, etc.) due to looming deadline pressures
• Failing to stop, regroup, and analyze the risks
• Taking a “big bang” approach to cutover with no contingency or backup should something go wrong

Management’s response, of course, was to switch program managers, and issue stronger demands to have a smooth system, but none of the changes or demands made much of a difference. Consultants were brought in to prioritize the many problems, but still, the complexities proved too much. It wasn’t until a Medicaid expert was brought in that things began to gel.

Like many project failures, it’s easy to point to the project management (and certainly there are many shortcomings there in this case), but the organization must share the blame as well if it insists on unrealistic deadlines and leads by fear (fear of shareholders, fear of competition, fear of management, etc.). None of these variables can make an unrealistic schedule more realistic.

It's really very simple. Either adequate resources must be committed, the expectations lowered, or a more piecemeal approach taken (or all three, if applicable). In any case, the schedule must be realistic and risks need to be managed.

Here's the full article. It's well worth reading, as are the reader comments.

Maine's Medicaid Mistakes - Editorial - CIO

Team Fun on the Cheap

Is your team suffering from infighting or poor morale?
Do you need a different way to celebrate a milestone on the cheap?

Consider the potluck. Dictionary.com defines the potluck as: A meal at which each guest brings food that is then shared by all.




Although it might be a bit of work for the project management team, organizing a potluck is a cheap way to get the team together. It is especially fun when there are international team members who can showcase food from their respective cultures.

Some tips for organizing your potluck include:

• Schedule it for a Monday. This gives people time to cook over the weekend.
• Create a sign-up spreadsheet with categories like appetizers, entrees, etc., so people can attempt to even the spread.
• For those folks who don't like to cook or don't have time, offer the "bring a staple" option. Every potluck needs plates, utensils, napkins, drinks, table cloths, a clean-up crew, etc. I usually use the "fastest timestamp wins" method for these.
• Book a large enough conference room for several hours around lunch time OR
• If you have a huge team, consider also having people bring in breakfast items (then extend that conference room booking)
• Consider creating a "party favor" for all project team members. We had mugs made with our project name and then filled them with an assortment of goodies in nice party plastic bags (pretzels, candies, nuts, etc.). This was also a team building opportunity because people shared well after the event.

What other ideas do you have for team building events? Let us know!

Recovering Troubled Projects; Seven Steps to Turn it Around

I just read a good case study about rescuing a troubled project, written by Jim Stewart on Chief Project Officer (which, incidentally, has a nice selection of articles).

Here are seven tips Stewart suggests:

1) Don't continue down a failed path. It's never too late to add controls.

2) Don't be afraid to cut your losses and terminate a project that's not generating value.

3) Be sure you have experienced, trained project managers. Keep the good, trainable ones. Reassign the others.

4) Be prepared to make tough decisions. Bypass groups that'll slow you down. Remove troublesome spots (or people).

5) Have adequate and appropriate resources. Allow project managers to focus on project management, not day-to-day technical details or deployment.

6) Don't hesistate to reconsider everyone's role. Avoid redundancy and joint-leadership situations.

7) Re-plan the project with team input. Avoid an unrealistic plan set by management. While management input is valid, only the team knows what's wrong with the project and how long everything should take. Getting team input insures a realistic schedule and garners team buy-in.

Here's the full case study with the lessons...

Chief Project Officer: Case Study: Recovering a Troubled High Tech Project

Microsoft Vista Project Management: Scope or Schedule Management ...

Microsoft struggles with Vista project management. Working the triple constraint, Microsoft adjusts scope and schedule - and, likely, costs are increasing as well. Article explores options for improvement, including ruthless schedule management, better requirements management, etc. ...

... "With Vista, Microsoft originally hoped to make major changes to the underlying code, adding in a new file storage mechanism called WinFS, along with all-new graphics and communications methods. It eventually had to pull out WinFS entirely and scale back several other architectural changes in order to make the project more manageable. " ...

Microsoft Vista Project Management: Scope or Schedule Management : Clouds over Redmond: Via ZDNet Australia ...

ERP Project: Keep Eye on Details ...

Firm publishes report on approach to challenging ERP business transformation projects. Current marketplace conditions are impacting the quality of ERP implementation talent even in the context of a strong methodology. This requires the client company to pay close attention to the project details. Be on the look-out for: Lack of transparency, limited bottoms-up planning to complement the top-down methodology, no iterim integrations with legacy systems to bridge gaps during the implementation, and missing current state analysis.

... "Based on its work helping numerous companies pull errant ERP projects back on course, DiamondCluster has identified circumstances that endanger projects and offers specific steps that can keep companies moving in the right direction. " ...

ERP Project: Keep Eye on Details: Via DiamondCluster: Red Flags Can Signal That ERP Integrators Are Off Course According to New DiamondCluster Report: Studies Show Many ERP Projects Still Run Significantly Over Budget and Behind Schedule. New DiamondCluster Report Explains Why and Offers Advice to Keep Efforts on Track ...

Why Projects are Late; The Top Six Reasons

Here are the top six reasons why projects are late and what we can do about it...

1) Unrealistic Deadlines - As we've reported here before, this is one of the most frequently overlooked reasons for late projects---and unfortunately, often the last thing people look at.

Solution: It's imperative for a project manager to defend the right plan and not give in to pressure to sacrifice good principles. If necessary, negotiate to time-box the project into multiple phases.

2) Customer/Partner Availability - I've seen numerous project managers over the years talk about the challenges they face keeping a project on schedule when they're waiting on a customer or business partner to do testing or sign off on some deliverable.

Solution: Set milestones, monitor progress, and raise an issue if the lack of availability will cause a delay. If necessary, negotiate a new project baseline---which may be quite appropriate if the customer and/or steering team agrees that a delay is acceptable.

3) Resource Availability - There's nothing worse than putting together a reasonable schedule only to have your key resources pulled off into different directions, but it happens more often than we care to admit.

Solution: Try to obtain full commitment up front for your resources' time. Even so, unexpected conflicts will happen. Same as #2 above, set milestones, monitor progress, and raise an issue if needed. Again, negotiation may be necessary, which can result in getting your resources back or in setting a new project baseline to accommodate the new priorities.

4) Uncertainty - Especially in the IT field, uncertainty is a given. At any time, unexpected circumstances may cause project delays.

Solution: Use rolling wave scheduling, planning the whole project from a high level, but only the nearest 90-day horizon in detail. Try agile approaches as well, aiming for prototypes and frequent iterations. Ideally, pilot the project, and aim for vertical rollouts (one group at a time). Build contingency into your schedule for known risks. Most of all, manage stakeholder expectations.

5) Management Decision - Sometimes, management makes a conscious decision to delay a project, either for strategic needs, changes in priorities, or any number of reasons.

Solution: If the delay is a management or customer decision, a new project baseline should be saved, with current metrics based on that. Note that it's also important to keep the original baseline, as that offers a different set of measures (mostly around organizational alignment).

6) Poor Estimates - Sometimes a project is late simply because tasks were underestimated or omitted from the schedule. Although this is not always the cause of project delays (and rarely the only cause), it tends to be the first one people look at.

Solution: Build experience and capture historical data by project category and activity. If the data isn't categorized it won't be useful. Create and maintain checklists of items to consider. Build project schedule templates. The most frequently overlooked areas in IT are: training, data-loading, cutover preparation, system network testing, adequate QA testing, and documentation.

Project Stage-Gates: NASA Improvement Opportunity ...

NASA receives recommendation to improve project management quality through stage-gate approach (knowledge points) to the project lifecycle and solution maturity. ...

... "A report released today by the Government Accountability Office (GAO) concluded that additional decision reviews are needed to ensure that NASA's projects meet their performance, cost, and schedule goals. ...

GAO’s recommendations include requiring that NASA projects demonstrate: that key technologies have reached a high maturity level before approving the projects for transition from the formulation to the implementation phase, that the design is stable before approving the projects for transition from the design phase to the fabrication, assembly, and test phase; and that the design can be manufactured within cost and schedule and meet quality targets prior to any decision to enter into production. " ...

Project Stage-Gates: NASA Improvement Opportunity: Via Democratic Caucus, Committee on Science, U.S. House of Reps: Gordon, Udall Urge NASA to Heed GAO's Project Management Recommendations ...

Risk Analysis

Oil exploration is a notoriously risky business. Add in the physical risk of deep water drilling and you can easily understand why risk analysis and management takes on a really high profile in the off shore drilling industry.
DNV is a long established maritime certification organisation and, with the North Sea oil boom, has moved naturally into the off shore oil exploration risk management and certification business.
This paper describes an approach to risk management for deep water exploration. It is written with a general approach and is adaptable to other styles of project and product.
A couple of perspectives that make it particularly interesting:
The risk analysis - and management plan - will be different for the organisation executing the project and for the contractors;
The categorisation of risks by Economy, Time and Performance - equivalent to Cost, Schedule and Scope. The familiar Probability/Impact matrices are represented for each of these and the authors use an interesting method of plotting the effect of risk mitigation plans on the analysis.
There is also extensive discussion of the risk management process, use of the risk register and communication. It ends with a couple of case studies that illustrate the approach nicely.
DNV Risk Analysis

Agile Project Management with Scrum

I have been wondering lately, what does agile really mean here?
This article says, Agile means responding to change - both technological change and changes in requirements perhaps due to customer demand and market opportunities.

It makes sense to me that this would be needed. The world is spinning much faster now and people expect content on the web, for example, to be relevant.

How does this differ from typical PM approaches? It has an answer there too...
-----
More traditional project management "command and control" approaches assume the relationship between the inputs and outputs of a software development process are stable and predictable and that the schedule of outputs will still be relevant by the time they appear. Scrum accepts the fact that things are going to change and takes an empirical approach.

In Scrum work is delivered in monthly "sprints". Each sprint delivers a single, usable piece of work called the "product increment". This product increment is immediately available for evaluation and use by the customer at the end of a sprint. Projects managed in a "command and control" style often have an infrequent release schedule. This can result in a gulf between customer expectations and reality. Scrum requires these predictable, frequent releases to ground customer expectations on demonstrated, working code rather than the false comfort of forecasts and reports. Short of an emergency, stakeholders aren't allowed to approach developers formally or informally with requests to do additional work during a sprint. This gives the development team enough stability to be able to complete a product increment without being distracted by the noise of external disruptions.
-----
Now that last part about not having stakeholders formally talk to developers is something that I try to enforce on my projects also. So, maybe it's not so different after all...to learn more visit:
ITWALES.COM - Agile Project Management with Scrum:

Scheduling is Dead, Bring on Chaos; So Says A Foremost Scheduling Expert

Project scheduling has no future whatsoever, and this comes from no less than Murray Woolf, the Managing Director of the PMI College of Scheduling's Scheduling Excellence Initiative (SEI).

This article, posted at PMForum is one of the better ones I've seen in a while (possibly because it's aligned with my philosophies). The premise is that, in today's day and age, the industry is headed toward more of a "give the people objectives and let 'em work it out" philosophy, which is completely opposed to the old "build a detailed schedule and make 'em follow it" mentality.

This is completely aligned with a value system that I've long subscribed to (and had posted on here at PMThink), and that is: To foster passion and accountability, we need to provide:

- Autonomy and Trust
- General Guidance and Principles
- Support and Removal of Barriers

This, of course, must be supported by having clear objectives.

Through all this, we also need to send a message that results are more important than blindly following rules. This doesn't mean that we needn't have processes, as people need a system in order to achieve consistent results; merely that we should give project managers the freedom to bypass certain processes if it's necessary to achieve good results. "Good" is the operative word here. Just meeting a date is not "results."

I believe that Mr. Woolf's article endorses my approach, and acknowledges that the following is where the future of project management is:

More organized chaos than it is controlled components.
More project facilitation than it is project scheduling.

This doesn't mean that planning isn't important either; merely that the act of planning shouldn't be confused with rigidly following the plan/schedule. As Dwight D. Eisenhower said, "Plans are nothing; Planning is everything."

As it is, and as Mr. Woolf rightly points out, project managers and "schedulers" are so bogged down in details and administrivia that they become more project reporters than managers. We need to observe where the future is headed and free project managers from the burdens of such fruitless details.

Instead, their efforts should be spent on adequate preliminary research, communication, facilitation, risk awareness, and other traits necessary to effectively manage a project.

For the full article, which I highly suggest reading, see Mr. Woolf's paper below...

PMFORUM, Connecting the World of Project Management - Papers

Project Failure Rates Soar; Blame the Estimates

How many times have you heard these statements from management?

"I didn't call this meeting to discuss whether we can meet the deadline. We're here to decide how we're going to meet it."

"What we've got to do now is to roll up our sleeves and do whatever it takes to get the job done!"

"I agree with you in principle, but this project is so urgent that we just don't have the luxury of doing it right."

These statements are all referenced in an excellent article by Conrad Weisert, titled "The Burden of Proof in Estimating." He attributes it to the fictional "Management By Cliche Handbook," but the statements and the poor results they usually lead to are anything but fiction.

With project failure rates not much better than they were five years ago, this article validates what I've been saying for a while: Most projects that run over budget do so because the original unrealistic estimate was provided under pressure from management.

It's critical that a project manager defend the right plan and negotiate tradeoffs in scope, time, or cost accordingly. Perhaps the best approach, and most consistently effective one, is to timebox the scope, aiming for realistic, phased deliverables.

It's also important when submitting a budget estimate, that the correct level of accuracy is stated (i.e. plus/minus 25%, or whatever is appropriate). PMI offers some guidelines, but those are just that---guidelines. A detailed bottom-up baseline estimate should only be provided after a detailed schedule is developed.

The bottom line is this. Weisert has a very simple principle: "In assessing the credibility of a project estimate the burden of proof falls on those who claim it can be done." This is sage advise. For the full article, read on...

Burden of Proof in Project Estimating

Project Managers: Green Means Go?

George Harrison discusses the need for project managers to recognize and react to indications of project failure. ...

... "Generally speaking, you and your business will not be able to make up missed milestones without one of two things: a reduction in scope and quality to your project or a major increase in project costs, whether it is to add more resources or to lengthen the duration of the project’s schedule. " ...

Project Managers: Green Means Go?: Via LocalTechWire: When Green Means Stop! in Project Management ...

Tags: Project Management, Project Manager

Agile vs Big-Bang Project Delivery; Argument Solved

For years now, proponents of realistic IT approaches have been touting the importance of agile or spiral development. And aficionados of traditional "plan everything up front" approaches have been counteracting this by stating the need to agree to a fixed scope, and stay on time and on budget.

Several weeks ago I mentioned an excellent book that addresses this subject; Software Projects: Evolutionary vs. Big-Bang Delivery, by Felix Redmill. I finally finished reading it, and it points out how to resolve the differences, with a reasonable and sensible approach.

Again, the book is expensive (well over a hundred dollars), but can be found used for around fifty dollars on Amazon.com.

Below, I've paraphrased and summarized the key points:

• Be sure to understand and state the business objectives up front. This is too high level for an adequate estimate, but it's a start.
• Then conduct a feasibility study, analyzing as much detail as possible before authorizing the project. Most organizations skip this step, with bad effect. Aim for an aggressive but realistic target.
• Beware of random constraints assigned by senior management, with no strategic cause. Most projects fail because they attempt to hold to unrealistic or arbitrary constraints. If necessary, document the risks of adhering to the arbitrary deadline and review with them. Negotiation tradoffs in scope, time, or cost as needed - or break the project into multiple phases.
• It's still too soon for a definitive estimate, but the results of the feasibility study should be submitted as an "order of magnitude" estimate, along with risks and a plan for mitigating them. This becomes the business case for the project.
• Make sure senior management understands that change is inevitable as the project progresses. But this change should be still be governed and weighed against the business objectives. Reassessment gates can be used to reset expectations of when the project ends.
• Not all change should require governance. Project managers should have the leeway to use their own judgment to change tactics accordingly as long as it's within the business objectives. They should not just "follow procedures."
• It should not be expected that all work will be done within the confines of the original document. For instance (and this is my example, not from the book), if implementing a purchased software project, a feasibility study would have been done before the software was purchased, configured, and tested. Upon configuration or testing, new discoveries/issues can (and probably will) occur. The only way to truly mitigate this is to do a pilot. Aside from that, expect changes.
• This is a HUGE culture change for most organizations on the part of senior management. Without this level-setting, management will expect all work to be held to the original estimate, and judge success against it. This is the key reason why most IT projecst are seen as failures. We must manage stakeholder expectations (and that includes senior management).
• Project progress should be weighed regularly against business objectives and not the completion of tasks. These objectives and the project's ability to meet them should be reassessed at each phase gate, with escalation of any variances to management. Again, this is the time to reset when the project ends, if necessary. This is also a huge culture change for senior management in most cases.
• Scope should be revised as needed and documented at each step, so there's a record of the approvals and rationale for changes. Reasons of variations should be captured as lessons for future estimating.
• Agile or evolutionary development is not an excuse to ignore change management. But change must be expected. To hold firm to a detailed schedule up front is not realistic for most IT projects.
• Maintain close contact with users throughout the project to assure success.

This sounds like a sensible approach, but does require level-setting with management. Again, many project failures are a result of not setting the right expectations with management. Otherwise, a project can be a complete success, but management is dissapointed. This destroys morale and unfairly judges the project as a failure.

I recommend the book for those who want to learn more, as the book goes into far more details and offers examples, processes, etc. Here's the Amazon link...

http://www.amazon.com/gp/product/0471933430/102-4494239-8790520?v=glance&n=283155

Troubled Project Dilemma: Fix or Kill?

We've all been faced with projects that run into unexpected problems. It happens to the best of us. Sometimes, despite the best of planning, things can begin to go south. The situation may be that the project now risks running overbudget or being delivered late, or it may be that unanticipated quality problems were discovered.

Our first action should be to not overreact and to try to fix what's wrong, working out alternatives if needed. But if all else fails, then we may be faced with a tough decision. Do we continue to fix it, accept the situation and manage expectations, negotiate a change in schedule, budget, or scope---or do we kill the project?

Similar to going bankrupt, killing a project late in the game should only be a last resort. Even then, there's a right way and a wrong way to go about doing it. The article below from High Context Consulting offers some good tips, most of all that an alternate solution must be proposed.

Specifically, it says:

• Build a case including alternate options to meet original needs.
• Gain support of stakeholders and a champion.
• Present recommendations to leadership.
• Do not play the blame game.
• Learn!
  
  Here's the full article...
  
  High Context Consulting � Blog Archive � On Killing Projects

Project Estimating; Triple Constraint Must Stay Firm

Here's a great article from TechRepublic about project estimating and forecasting. It cautions that one of the worst things to do is to try to force a project to fit within an arbitrary management deadline. That means project managers must defend the right plan or suffer with poor results.

A properly estimated project must be based on planning, and be managed to the triple constraint of scope, time and cost (and of course, at PMThink we've discussed other potential variables, such as quality, risk, customer satisfaction, and more).

Here's TechRepublic's advice to CIO's:

Project managers talk about a project’s “triple constraints” of scope (work), time (schedule), and cost (budget)... For the team to make decisions that are closely aligned to the way you would like them to be made, you must clearly state the project priorities. There’s no such thing as “all three variables are equally important.”

Read on for more details or proper estimating and forecasting...

How to accurately estimate and forecast in project management

Project Management Graphical Innovations

I've posted in the past about the limitations of current project management reporting (are Gantt charts really the best we can do in the 21st century?).

PCF has some intriguing reporting alternatives on their site for project schedule, resource, and earned value tracking, as well as high level program performance.

Check it out...

PCF Ltd - Giving You Complete Control

Earned Schedule instead of Earned Value?

This presentation from PMI conference in UK this year describes the problems with Earned Value Management. One is that Earned Value is useful only in the early stages of a project for providing schedule management information - the SPI will always be 1.00 at the end of the project. Another is that most people don't understand schedule in terms of budget - and the use of accounting practices in project management probably has a lot to do with that!
The proposed approach uses the same basic information as SPI but expresses a Schedule Variance in terms of time rather than money. The SV(t) is the difference in time between the the status date and the date for BCWS equal to the current value of BCWP.
Earned Schedule

Project Implementation; Software Rollout Approaches

When analyzing alternate approaches for rolling out a new software product, consider information density versus percent of population.

For example, you can start with low information density (less functionality, fewer features, etc.) in a large percent of the population (or for everyone), and then roll out more features over time.

Or you can start with high information density (heavy or full functionality) for a small percent of the population (i.e. a pilot group), and then roll it out to wider audiences over time.

Neither approach is wrong. It all depends on the situation, the nature of the product, and where the risks lie.

For example, if the audience for the software can be isolated easily and there are no major issues with rolling out to wider audiences piecemeal, then it may pay to start with high information density in a pilot group.

But if there are major risks to rolling it out piecemeal (such as a need to maintain multiple systems, etc.) and basic features will do for phase 1, then the alternate approach might be a better choice.

One thing's for sure. To begin with high information density in a large or total percent of the population is usually a mistake (unless the full information density is necessary for the product to work, in which case the schedule needs to include time for full rollout and extra testing).

Just some things to think about when planning your next software rollout.

Top 3 Qualities of a Successful Project Manager

Although there are many qualities that a good project managers should have, it has occurred to me from recent observations that there are really 3 key ones. If nothing else, a project manager needs to be:

• Organized
• Assertive (not to be confused with aggressive)
• Empathetic

They need to be organized in order to keep up with all the events and details going on during the project; including issues, schedule monitoring, communications, status reports, risk monitoring, and a whole host of other things.

They need to be assertive when dealing with resistant stakeholders, overbearing managers, and lackadaisical team members.

And they need to be empathetic to the needs of customers, stakeholders, team members and all sorts of constituents. To be overly assertive or too soft is equally ineffective, so both are needed in balance.

The rest, as they say, is details

EVMS Earned Value Management: Federal Agencies Lag Behind

Primavera studies the adoption and implementation of earned value management processes and systems (EVMS) in federal information technology organizations. Current assessment shows that agencies lag behind on implementation versus their EVMS targets. ...

EVMS Earned Value Management: Federal Agencies Lag Behind: Via Primavera: Study Reveals Disconnect Between Perceived Merits of Earned Value Management and Federal Agencies Readiness to Implement ...

... "Specifically, the study indicates that the federal IT community agrees with OMB that EVM delivers improved project outcomes, with 60.6 percent of respondents reporting that EVM is very or somewhat important to achieving their capital investment goals. Despite this value perception, results do not demonstrate agencies movement from belief to action, with only 37 percent currently utilizing EVM and even fewer prepared to train or hire personnel skilled in EVM within the next 12 months. Respondents cited their top challenges to EVM implementation as unfamiliarity with EVM and lack of trained personnel. These findings indicate that agencies will not only have difficulty developing EVM implementation plans in time for the December 31 OMB deadline, but also will face challenges implementing documented plans. EVM processes, systems, and software enable the continuous assessment of project performance and status - providing a methodology that can help agencies effectively measure project alignment with resources and goals by comparing status to original plans and end goals. EVM can help agencies achieve green marks on the President's Management Agenda scorecard. To achieve and maintain this high score, agency projects must stay within a 10 percent variance from their cost, schedule, and performance goals. Further, OMB issued a memorandum in August 2005 requiring agencies to utilize EVM Systems (EVMS) on all new major IT projects. The memorandum requires development of written policies outlining agency-specific plans for EVM implementation by December 31, 2005. Agencies must also evaluate exiting, cost, schedule, and performance of ongoing IT projects and take any necessary corrective actions by March 31, 2006 and before devoting any FY06 funds to associated projects. In support of this effort, OMB is working with the Federal Chief Information Officers (CIO) Council to develop a model agency EVMS policy for IT projects ... " ...

Project Management Inefficiency: Manual Crisis Management ...

Tim Kaufmann explores the response of the Office of Personnel Management to the Katrina disaster and how inefficient IT systems project management requires the agency to employ manual and outdated techniques during a time of crisis. ...

Project Management Inefficiency: Manual Crisis Management: Via Federal Times: Hurricane pulls benefits manager out of retirement ...

... "OPM has been working for years on a system to convert paper files now stored in agencies' headquarters offices to an electronic database. Developing and deploying the system is behind schedule due largely to inefficient project management, the Government Accountability Office said in February. " ...

PMThink! resources on business continuity and disaster recovery projects:

• Business Continuity Project: Key Part of IT Strategy ...


• IT Risk Management: Disaster Recovery Planning: Forward Placement


• Project Manage Business Continuity Events

Project Control and Leadership; The Two Faces of Project Management

There are those who think of project management as primary a control function (i.e. controlling cost, schedule, scope, etc.). Then there are those who view project management as primarily a leadership function--leading and facilitating a large team to complete mission-impossible milestones and removing barriers as fast as they appear.

Well, in reality, it's a little of both. But to really be effective in the latter, it's often helpful to have some assistance in the former. I've mentioned this before but it's worth mentioning again. If it's at all possible to have a separate person handle much of the project control and administration funtions (owning the issues list and risk list, maintaining the schedule, handling project accounting, etc.), it'll make it that much easier for the project manager to be successful with the all-important job of leading the project. This is especially important for large projects.

All to often, project managers get so caught up in the "mechanics" of project management that they forget to actually manage the project. This doesn't mean the project manager is oblivious to the issues list, risks, and schedule, merely that a separate person maintains these items. On the contrary, analyzing the schedule, issues and risks are a key part of leadership.

International Project Management Day is Coming: November 3, 2005

Get ready, because International Project Management Day is coming your way on November 3rd!

According to the official International Project Management Day website:

The international project management day is intended to encourage project based organizations worldwide or organizations who utilize project management methodologies to schedule some type of recognition event within their organizations or coordinated locally with others to truly demonstrate appreciation for the achievements of project managers and their teams.

What kind of event do you have planned? Might be a good excuse to take your project managers to lunch.

Planning for Scarce Resources

One of the concerns that comes frequently from clients is that their people work on lots of different kinds of stuff so planning their time for projects is difficult. And it's true. A common circumstance in IT shops, in R&D labs and in many other situations, is for someone who developed something originally to get pulled into responding to questions and supporting it for eternity. This is the support dilemma. It worries project resource managers because the work load for the support people can be unpredictable. The support call cannot be planned or scheduled.
So the temptation is to throw up one's hands and say because this group of activities cannot be planned, it's pointless trying to plan anything for that resource. This extreme is unnecessary. You will have to live with a bit of uncertainty but there are good statistical approaches to dealing with uncertainty.
The first, essential step is just to list the different kinds of stuff that a resource might work on. Then estimate the rough order of magnitude of effort for each kind. Support tasks will be an average over time - not necessarily constant (more urgent support calls during year-end, product launch, etc.). That will give a base of committed time for that resource - leaving a known amount for other (project) work. Support work is typically treated as high priority.
Historical data may give some clue about the level of variability in the level of support work - an average of 2 hours per day may in fact be fairly predictably 1.5-2.5 hours every day - or 1 day in 4 completely taken up with support. This pattern is important because it affects the confidence in the ability of the resource of being able to work to a project timetable.
One simple approach is to schedule only a part of a scarce resource's time for high priority projects. The balance, the float, is provided by assignments to low priority projects. If it's important to have someone dedicated to a single high priority (please, not to 5 high priority projects!), then you cannot afford to have them dragged off to provide support.
This paper includes some interesting references to resource planning and a description of the rolling wave approach - which has been mentioned in other posts on PMThink!
Managing Project Performance: A Proposed Model (Part 1 of 3)

Basic Project Communication

Research has shown that in communicating we spend approximately 45% of our time listening. Moreover, the average listener understands and remembers approximately half of what has been said, immediately after a presentation. Within 48 hours this decreases to 22%.

To help get your message across, aim for redundancy in your message and in the medium. If possible and above all other media, you should opt for face-to-face communication.
If you really need to get a message across to a team, I suggest the following:

• Prepare the message in writing (or at least an outline of it); create pictures when possible
• Schedule a meeting and send your written message with the meeting notice
• Bring "visuals" to the meeting (e.g., project the presentation on the wall, prepare handouts for everyone)
• To the extent possible, ask people to explain the message back in their own words to ensure that it is understood
• Follow-up after the meeting with meeting notes (stating your message again clearly)

With all of these opportunities for people to 'get the message', there is a much better chance that they actually will.

Project Scheduling on the Back of a Napkin

I'm sure most of you have come across the old curmudgeon who says "I could have planned that on the back of a napkin and done a better job." Well, in some cases, that may just be true.

I'd go so far as to say that a rough schedule done on the back of a napkin by someone who's been around the block is more reliable than a detailed project schedule in MS/Project by a rookie, or even a mediocre, project manager. I've seen it done. Hell, I've even done it myself in the past (and came up with better results than the PM assigned to the project).

Bu don't try this at home, folks. I'm not saying that this is an effective or even a correct method of scheduling projects. I'm merely illustrating the importance of experience and good analytical skills. So, if you lack experience in the area that you're managing, be sure to include the subject matter experts and ask them to point out all the issues and pitfalls!

Managing Superstar Project Teams

In case anyone missed it, Computerworld ran a great article in August about the nuances of managing virtuoso teams. These teams are usually pulled together for a high profile, short duration project, where they are co-located and given carte blanche to break the rules and get the job done. Typically done in a skunk-works environment, the focus is usually on major milestones, with a weekly or even daily schedule posted for all to share.

The key is to get the best people you can on the project, which also means that a special type of leadership is called for in order to manage people that are used to working independently. Check out the article, which talks about some of the particulars of managing such a team.

Throw Out the Rules - Computerworld

OMB EVM Rules: Software Supports Capital Project Oversight ...

Software enables compliance with OMB earned value management EVM rules, which supports better oversight of capital projects ....

OMB EVM Rules: Software Supports Capital Project Oversight: Via xpdoffice - A Division of SSSI - Offering Web-Based Timesheet and Project Management Software

... "xpdient, Inc., a division of Scientific Systems and Software International (SSSI), announced the release of a new module of its successful xpdoffice solution to address new Earned Value Management (EVM) rules propagated by the federal government's Office of Management and Budget (OMB) via circular A-11, Part 7, titled Planning, Budgeting, Acquisition, and Management of Capital Assets. The release occurs as OMB officials are becoming increasingly persistent in urging agencies and agency contractors to adopt EVM oversight of major capital projects.

Becoming effective in the near future, rule changes to the Federal Acquisition Regulations will standardize EVM execution and use for all major federal government acquisitions, including information technology services. Widely used in commercial markets, earned value management is a standard way to measure a project's progress, forecast its completion date and final cost, and provide schedule and budget variances along the way. By integrating these capabilities, xpdoffice provides consistent indicators enabling project evaluation and comparison. " ...

xpdoffice is a web based Business Automation Software (BAS) solution that streamlines enterprise management and delivers improved project financial reporting. xpdoffice modules include HR, Contracts Administration, Time Management, Document Management, Knowledge Management, Purchase and Inventory, Project Management, and Expense Management.

Project Risk-Based Cost Management; Is RACM The Next Big Thing?

The Defense industry brought us Earned Value and proved that Critical Chain could work. Now the DoD commissioned the Institute for Defense Analysis (IDA) to test a new cost control theory called RACM (Risk Analysis and Cost Management).

The results of the study showed that RACM can offer significant reduction in project costs and excellent cost performance management. RACM offers a method to determine and manage an appropriate risk reserve level (much like Critical Chain focuses on buffer management for schedule control). It also uses a risk multiplier (called Ps or "Probability of Success") for costs at the WBS element level.

But RACM is not being positioned as a replacement for Earned Value Management. Instead, it can be used to complement EVM.

For more info, see the website for RACM, Inc. They also offer a 60-day Evaluation Beta Model.

RACM Home Page

Project Schedule Critical Path ...

Project Schedule Critical Path: Via Yackity Blog Blog: Critical Path in Schedule Management

Post on project management critical path concepts ...

... "Project Management Network Diagrams are helpful in determining where most of the schedule project risks will occur. A critical path is made up of activities that cannot be delayed without delaying the end date of the project. " ...

Conquer the Project Communication Conundrum

My favorite project-related formula explains clearly why as a team grows, it gets harder to keep everyone "on the same page."

# possible communication channels = n(n-1)/2
where n = the number of people on your team

In other words, if there are 3 people (n=3), there are only 3 possible communication channels. (Hint: picture drawing as many lines as possible between 3 points - you get a triangle – only 3 paths).
Increase the number of people (or points) to 5 and suddenly there are 10 communication paths.
Increase the number of people to 10 and WHOA, there are a whopping 45 communication paths!

No wonder keeping everyone on the same page is so hard!

What's the answer to managing this communication channel explosion? A few thoughts that may help:

1. Divide the work into "bite-size chunks" that small teams can work on (for those of you from PMI-land, this could equate to work packages in your WBS)
2. Collocation (yes, I spelled it right) i.e., physically getting everyone to work in the same room for the duration of the project; with collocation, communication is:
• Faster - less meetings are needed - just turn your chair around or walk across the room
• Easier (to keep everyone on the same page) - everyone can hear everything and jump into a conversation in midstream if the message seems wrong
• Better - as people get to know one another because they are "living" in the same space, they learn how to more effectively communicate with one another
3. Build and follow a communications plan (see also my post from 10/03/2005, Project Communication Handbook & Tools)
4. For people who can absolutely not be in the same room, first, get to know one another in person (highly recommended although not always possible); then use the phone and instant messaging to keep in close contact
5. Schedule time for team fun! (Highly important!) People that have fun together perform better and are more willing to communicate. We are human after all.

Hopefully these ideas are helpful to you and your project. Let us know your tricks for conquering the project communication conundrum!

Rolling Wave Scheduling; It's All About the Granularity

I've heard many traditional project managers shun rolling wave because they feel it's like "winging it," when in fact it couldn't be farther from the truth. On the contrary, even with a Rolling Wave schedule (where we plan each 90-day horizon in detail as it approaches), we still need to define the overall project scope and objectives. And we should even plan the whole schedule in as much detail as we know.

It's just that the future phases will be fine-tuned in further granularity (and typically rebaselined accordingly) as their horizon approaches. Ideally, this will have no bearing on the overall scope or end date. And if it does, it can be submitted as a scope change.

With this in mind, I do not see any significant differences between Rolling Wave and traditional approaches, save for more flexibility and realism (and less wasted time up front trying fruitlessly to plan unknown details far out on the horizon).

Project Schedule Seem Impossible? Consider Skunk Works Approach

If you're ever faced with a project with a seemingly mission-impossible due date (geez, has anyone had one of those?), consider lobbying for a "skunk-works" approach.

The term, coined by Lockheed-Martin, defines a small group of people given an extremely important project with an extremely short timeline, where all normal bureaucratic rules are thrown aside in favor of a rabid focus on schedule.

The group is typically co-located and is given carte-blanche to achieve their goals without executive and administrative burdens. There's a strong focus on milestones and near-daily interaction with vendors.

Also, see Max Wideman's definition of "Quick Reaction Capability," which is in essence the same thing...

Wideman Comparative Glossary of Project Management Terms v3.1

How many elements are there in the triple constraint?

In addition to the normal triple constraint elements:
1) Time (or schedule)
2) Resources (effort and/or budget)
3) Scope
discussed in this article, there are two other important elements to every project:
4) Quality
5) Customer Satisfaction

What if you delivered the scope on time and on budget but it wasn't up to the quality standards of your customer (or user of the product or service)? Would your project be a success. I think not! And what if you delivered the full-scope, it met the customer's quality expectations, was delivered on time, on budget, but you and your team were extremely difficult to work with? Would the project be a resounding success in your customer's eyes? Would they want to work with you again? Most likely not.

The article is dead on, though, in suggesting that the PM should be sure to ask the sponsor(s) to prioritize the "triple" constraint at the beginning of each project. Just remember that there are 5 elements and they are all important!

Triple Constraint--Friend or Foe?

Project Resource Planning; Is there a Gap in the PMBOK?

According to the PMBOK and traditional project management practices, project initiation begins with the project charter. Never mind that the real value-add is in the preparation needed to tie the project to organizational strategy (which arguably links to the portfolio management process) and to select the right project approach (which would end up on the charter). Ideally, the project manager should be more involved in up this up-front options analysis, which would also require solicitation of specialized resources very early in the game.

In addition, the subsequent planning processes include WBS and schedule development (both of which are best done as a group effort with stakeholders, as the PMBOK points out), yet there is no mention beforehand of soliciting resources for that work. These stakeholders are not often readily available, so this appears to be a gap.

Although the PMBOK rightfully suggests engaging stakeholders in the initiating and planning processes, the first time resource planning is mentioned in the PMBOK is following the schedule development. Could it be that the PMBOK doesn't consider stakeholders resources?

Yes and no. As it turns out, the PMBOK assumes these resources are readily available, as part of what it calls "Enterprise Environmental Factors." This might relate to the fact that many organizations (and remember, the PMBOK exists to document common practice, hence the name "standard") do not track resources during initiation and planning, but only begin doing so during execution.

Ultimately, the initiation and planning phases drag out because stakeholders aren't available and/or nobody is tracking progress during these phases. Some organizations are starting to realize the benefits of planning and tracking the "initiation and planning" activities (instead of planning to infinite capacity), so by the time the next PMBOK rolls around this might be common practice.

So, maybe this isn't a gap in the PMBOK after all, but instead, a gap in common practice.