Halt Who Goes There ?

The VA executes a reset on the under-performing segment of its project portfolio. ...

... "Each of the 45 projects will be temporarily halted. No further development will occur and expenditures will be minimized. A new project plan that meets the requirements of Program Management Accountability System (PMAS) must be created by the project manager ... " ...

Via Department of Veterans Affairs: Increased Accountability

Project Value Delivery

I like the idea of transforming business cases into the value delivery story with the enabling plan. We should strive for this in the information technology space. Our historical challenge is being able to identify and articulate business value in the first place. But, as we mature, planning for the achievement of value is the next goal. Project plans will not be able to end at system go-live or stabilization. Plans will have to be extended to user adoption, competency demonstration, and organizational process performance and maturity. ...

... "So, we’ve got to change the business case and make it value-focused; centred around the value proposition. Then we’ve got to make the project plan value-focused ... " ...

Via CIO Australia: The New Business Case

Manage Uncertainty with Liquid Plans

Project Forecasting and Uncertainty

Yesterday, I posted about the need to focus on time remaining, using a driving analogy. The premise was that, if we were traveling from Philadelphia to New York and we were at the New Jersey Turnpike entrance (and assuming arriving on time is a critical success factor), the best predictor of success would be to determine how much time remains on our trip.

But what if arriving on time were not the most pressing need? And what if we increased the uncertainty factor? Is "time remaining" still something we can and should monitor?

Let's take IT research projects, for example, which tend to carry great uncertainty. Using an agile approach, the team builds prototypes, and the deliverables get ever closer to "the truth" as the project progresses. If we used a fixed set of iterations, and/or fixed-time iterations, we still benefit from focusing on time remaining, possibly even more so. The only difference is, we're operating in increments.

And even if time is not the ultimate concern, any customer will still want to know "How long will it take before I see something of value?", and usually, "How much will it cost me?" These are the basic fundamentals of good customer service. We still need objectives and scope statements, even on agile projects. It's just that we recognize uncertainty more.

And speaking of uncertainty, proper preliminary research and planning can often help reduce it, and contingencies or buffers can help prepare for the unexpected. Piecemeal deliverables (iterations) can also help, as learnings can be applied to the next phase.

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

Project Management and Driving: Staying Tuned In

It had occured to me the other day that project planning is a lot like driving a car. If you constantly look down at the road in front of you, you won't be prepared if traffic suddenly stops or changes pattern. It's better to look out at the near horizon.

And if you listen to the radio for the traffic reports, you'll be able to avoid problems before you even see them.

It's the same with project management. We need to focus on the current planning horizon as far as we can reasonably see (usually we can only see three-to-six months out with any degree of accuracy). And it's equally important to stay "tuned in" through networking, reading what's happening in your organization and the world, visiting your customers and stakeholders, and practicing MBWA (Management By Wandering Around).

The more we're tuned in to internal and external activities that could impact the success of our projects, the better position we'll be in to address problems proactively and head off a traffic jam or a change in pattern.

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

Project Management Imperatives: Ten Keys to Success

Someone recently asked me what I felt the critical success factors were for any project (i.e. what were the top "must do's"). Although I can think of many more, here were what I felt were the top ten:

1) Get the roles right. (Insure accountability; use a RACI chart or Responsibility Matrix so roles are clearly defined. Insuring people understand their commitments up front will avoid problems later.)

2) Get the goals right. (Make sure all the key stakeholders agree on the goals. I've seen more projects go wrong for this reason than any other. Time spent here will pay dividends later.)

3) Get the current scope right. (I say "current scope," because change should be expected. Projects by default contain change because they are unique in nature. It's not whether you'll experience change, it's how you analyze the potential impacts and manage the approval of the change that counts. Agreed-upon and approved scope changes are perfectly acceptable, with one caveat: It's often wise to set a limit to the number of times scope can be changed for the current product release, and defer some changes to a subsequent release, else value gets delayed.).

4) Obtain commitment from the business, customers, and other stakeholders as to their part in the success of the project. (Many projects derail because the customer doesn't live up to their side of the bargain, doesn't understand their side of the bargain, or some other necessary constituent isn't cooperating for various reasons. Obtain the right commitment up front, starting with senior management.)

5) Determine the critical success factors and risks. (Critical success factors and risks go hand in hand. Many people ignore this or sweep it under the rug, and accept any related risks as a given. The critical success factors will identify related risks and help set expectations).

6) Set expectations. (This is frequently overlooked and is a key cause of failure. The sponsor, customers, and anyone impacted by the project must be given realistic expectations for what is needed from them, how long the project will take, how much it will cost, what the uncertainty factor is, what the available resources are, and anything else necessary to avoid surprises and/or an under-equipped effort.)

7) Beware of conflicting directives. (I call this the "Robocop Syndrome." In the film, Robocop, the titular robotic policeman goes on full tilt when he encounters directives that conflict with his primary directive. I see this happen often in organizations where a project sponsor demands something that is in conflict with other key stakeholders' wishes and/or top organizational directives. This could be covered under "goals" or "expectations," but it's so important that it warrants its own point. The project manager must head this off at the pass before the project goes down a rat hole it won't recover from.)

8) Plan Collaboratively. (The act of planning is not an isolated exercise. It's a collaborative exercise and should be done with the project core team and subject matter experts via some sort of facilitated brainstorming session---possibly with sticky labels on a wall.)

9) Beware of unilateral and granular "one-size-fits-all" solutions. (This is often ineffective, both as a project management methodology and a process implementation policy. Look at the big picture, and the potential variations. Keeping a framework high-level can allow for greatest flexibility and adaptability. Aim for principles over rules wherever possible. Use rules when safety is involved, regulatory requirements exist, or exact accuracy is needed---per Marcus Buckingham's guidelines from "First Break All the Rules.")

10) Don't let rank set you off course. (Often, a senior manager pulls rank and makes requests that are either detrimental, unwise, or in direct conflict with organizational goals. When this happens, see rules 6 and 7. It is the project manager's responsibility to set the right expectations, warn of potential risks, and head off potential conflicting directives at the pass.)

There it is. My list of "must do's." Project management isn't rocket science. In fact it's not a science at all. It's more of an art. Hopefully, the guidelines above can serve as a useful palette.

Project Weekly Tasks: Google Personal Homepage

Neat widgets to webify your project tasks and maintain visibility to your weekly work plan, if you use Google's homepage and personalize it. ...

... "You can now review your tasks alongside your calendar, mail, weather forecasts, and feeds (you can choose from hundreds of gadgets to personalize your page). " ...

Via Remember The Milk - Blog: Track Tasks with Google Homepage

Traditional vs. Agile Project Management: All You Need to Know

Here's the best article series I've seen to date comparing traditional "plan-driven" PMBOK practices to Agile "value-driven" approaches. It's a four-part series by Michele Sliger on StickyMinds.com.

Enjoy...

Column info : Relating PMBOK Practices to Agile Practices - Part 1 of 4

Project Management Training: Foundation For Success

With federal IT investment slated to increase, info technology professionals in government would be well-served by training in a foundation of project management basics. ...

... "officials interviewed for the study said their teams lacked or may lack sufficient training to effectively estimate costs, identify risks and develop baselines from which to plan project costs, schedules and technical requirements. " ...

Via Federal Times: Link

Extreme Project Management: Reality Rules

I just finished reading Doug DeCarlo's book, Extreme Project Management. I met Doug at a recent PMI event we both presented at. Not only is his keynote presentation a crowd pleaser (hint: he plays the drums to illustrate the pace of a typical project and uses Noah's Ark as a sample project from the "ultimate Sponsor"), but his book is chock full of practical, immediately usable ideas.

I was amazed at how much his philosophy mirrors my own, with a focus on simplicity, value, results, and the understanding that change is inevitable. A key point of Extreme Project Management is that reality rules. Plans are nice, but then results must drive further planning instead of assuming reality will yield to the plan.

As an example of simplicity, consider what he calls "The Four Business Questions":

1) Who needs what and why?
2) What will it take to get it?
3) Can we get what it takes?
4) Is it worth it?

As another example, check out his "Three Sentence Project Skinny":

1) Who will do what for whom?
2) This project will be considered completed when: ___
3) Why? This project supports the organizations objective to: ___

The book also offers handy checklists (such as what to ask the sponsor during the first and secend meetings, etc..), the 4 Accelerators, the 10 Shared Values, the 7 Win Conditions, and more.

Although the book is the size of the Encyclopedia Britannica, it's extremely readable and has diagrams that bring together all the concepts in the book. I highly recommend it to anyone looking for a book grounded in reality as opposed to academic theory. Above all, this will help project managers succeed where the rubber meets the road---communicating and dealing with stakeholders.

Amazon.com: eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility: Books: Douglas DeCarlo

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

Innovation Needs a Process Too

Gerald "Solutionman" Haman was recently interviewed on Innovation Tools about...well..his innovation tools. And he has quite a few. An impressive list of clients have used his KnowBrainer pocket tool to generate ideas that directly led to huge profits.

The tool makes use of his "Accelerated Innovation Process," which outlines four steps. According to Haman's site, "the four steps include: (1) Investigate Needs, (2) Create Ideas, (3) Evaluate Solutions, and(4) Activate Plans." Haman stresses the importance of "continuous innovation" as opposed to being a short-term or one-time activity.

When you think about it, these four steps are very much in line with Dr. Deming's classic "Plan-Do-Check-Act" model for continuous improvement. Not a bad framework for project management either.

Here's the full interview.

Interview with Gerald Haman, SolutionPeople - from InnovationTools.com

Project Management Texas Style ...

The plan is made. The team is resourced. The baseline is set. ... Help the team have fun and focus. ... Project management inspiration from a great coach.

... "The game planning is over and I don't need to motivate this team. My job now is to settle them down so they can relax, have fun and focus when we need to focus. They can laugh and dance in the locker room but to win we need to balance being confident and focused. " ...

Via Every Game Counts: Texas Coach Mack Brown Blogs about the 3 Things that will Determine a Longhorns Win against the Buckeyes ...

Einstein Project Management Tip #2: Think Flexible

In keeping with our Einstein theme, here's our next project management tip from the great thinker himself.

"As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality."

While Albert Einstein was referring to the laws of mathematics, surely this applies equally to project plans. We lay out in fine detail what we think is the ultimate plan that supposedly reflects reality. We make what we think are valid assumptions. Then, the minute it is published, things change. Life has a habit of doing that, despite our best intentions.

But we still need to go through the act of planning if we are to think through the risks and have a good chance at success.

Therein lies the paradox. We need to plan, and then we need to constantly revise the plan to match reality. Then we need to plan again. It's a continuous iterative process of course-correction. Perhaps it's why Eisenhower said, "Plans are nothing. Planning is everything."

For most projects, the old adage,"Plan the work and work the plan" should be taken in a different context than its original intention. We need to plan the work, and then we need to "work the plan" (meaning "continuously adjust the plan so that it remains adaptable") , as opposed to merely working "to" the plan.

Stay tuned for more Einstein project management tips.

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 Lessons From the Other Napoleon (Hill)

I've written plenty about project management lessons from Napoleon Bonaparte. But there's another Napoleon with equally valuable lessons---Napoleon Hill, author of Think and Grow Rich.

For those not familiar with Napoleon Hill (who, ironically, also found inspiration from Napoleon Bonaparte), he wrote Think and Grow Rich in 1937 after spending years of research on the habits of rich and successful men at the request of Andrew Carnegie. For his book, Hill interviewed some of the most famous achievers in history, such as Thomas Edison, John Wanamaker, Charles Schwab, Henry Ford, Woodrow Wilson, FDR, and others.

From the book, here's how Napoleon Hill describes the way to go from desire to riches (by substituting the word "money" with "objectives," we can apply the same lessons to successful project management). My comments are in brackets.

1. Fix in your mind the exact amount of money [exact objectives] you desire. It is not sufficient merely to say, "I want plenty of money." Be definite as to the amount [Same with objectives. Be specific].
2. Determine exactly what you intend to give [committments] in return for the money [objectives] you desire.
3. Establish a definite date when you intend to possess the money [objectives] you desire.
4. Create a definite plan for carrying out your desire, and begin at once, whether you are ready or not, to put the plan into action.
5. Write out a clear, concise statement of the amount of money [scope and objectives] you intend to acquire. Name the time limit for its acquisition. State what you intend to give in return for the money, and describe clearly the plan through which you intend to accumulate it.
6. Read your written statement aloud, twice daily, once just before retiring at night, and once after rising in the morning. As you read, see and feel and believe yourself already in possession of the money [objectives].

Hill once said, "A goal is a dream with a deadline." He knew the importance of setting target dates and looking at a concise statement of your goals and committments daily. This can be likened to a scope statement and milestones list, which should be read regularly and not stuffed in a folder.

He also discovered the power of positive thinking, what one might refer to as "thinking the future into existence" (hence the title THINK and Grow Rich). He found that, just by thinking of your goal regularly, you attract that which you need to achieve it.

In all, the book offers 13 steps to achieving your desire, be it money or anything else. It should be noted that the book is not just about acheiving money and gets into metaphysics, etc. as well. There's a reason why it has sold 15 million copies to date (the best selling self-help book of all time).

I highly recommend the book to anyone who is trying to achieve a goal, which should be everyone, and CERTAINLY should be every project manager.

For Successful Projects, Think Hospitality

OK, I'm still thinking about the Bahamas. One thing I couldn't help but notice while I was there was a huge project that Cable Beach Resorts is undertaking, which will combine the Wyndham, Radisson, and Nassau Beach resorts into a sprawling mega resort of "sister" hotels with an integrated waterscape to compete with Atlantis.

It began as an $85 million project, but is now estimated at $2 billion (not sure of the reason, perhaps scope creep, surprise costs, or other unknown factors, but more likely this began as a joint renovation effort and evolved into a more cohesive whole as they saw the potential). However, what struck me is the way that they're doing it in phases to minimize the impact on guests. For instance, at the Radisson, where I stayed, they'll do one wing at a time, and during the interim will allow guests to use the facilities across all three resorts. In addition, they communicated heavily to travel agents, the media, and current guests.

It just reinforced to me that all projects, regardless of industry, should be treated as hospitality projects, with customer impact and communication a key part of the plan (and more than a little excitement and fun thrown in for good measure). Just some food for thought.

Software Glitch Fells Medieval Monster

Miss us? Even PMThinkers need to take a few days off for the holidays now and then!

We return with news of a software glitch that has caused the delay of Grendel, a $2.8 million opera about a medieval monster (as reported in Computerworld). I think I've worked with some computer systems that were like medieval monsters, but that's another story.

The LA world premiere was supposed to occur May 27, but has now been delayed until June 8, with the opening performances reclassified as "preview performances."

Apparently, the computer system was supposed to operate a huge, elaborate moving stage.

This sounds like the "perfect storm" of project risk---an extremely complicated software endeavor with high uncertainty, a firm "go-live" date most likely booked well in advance, and no contingency plan (since "the built-in stages and moving props are too heavy to be operated manually").

Here's the full article...

Computer glitch delays opera opening

Project Management Lesson from Carpenters

No, not the brother and sister duet, I'm talking about real carpenters. There's an age-old axiom used by carpenters: "Measure twice, cut once." Experienced carpenters know that there's no turning back if you made a mistake measuring once the wood is cut.

This is good advice for project managers as well. Many errors, and many hours of rework, can be avoided if you take the time up front to do the proper research, planning, and risk analysis. It's well worth checking your plan twice, even though circumstances are likely to cause you to deviate from the plan. But even those risks can be mitigated with proper research and meditation up front.

Just like carpentry, the later mistakes are caught, the more costly and devastating they are likely to be. It's better to spend a little extra time up front on your projects to increase the overall speed and success of the project.

Join the Project Management Revolution; The SOPM Model Takes Shape

OK, I've been fleshing out the Service-Oriented Project Management (SOPM)™ model, and have come up with a more memorable and catchy representation of the four steps, although the actual content is pretty much the same.

The acronym for the four phases is UP-IT (which can symbolize "upping" the level of customer service, saying "up yours" to old ways of doing things, or "upping" the success rates of IT projects---in which case the "it" stands for "IT").

Ready??? Drum roll please......

The four phases are:

• Understand
• Prepare
• Iterate
• Transform

Here's a revision of my previous post on the topic...

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 and what they need to be successful.

2) PREPARE ... After helping the customer obtain approvals if needed, 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... Using the axiom, "Think bold, implement safely," plan, design, build, test and pilot the solution before attempting a full scale implementation. Encourage innovation. 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) TRANSFORM... After each project phase and at the end of the project, evaluate and document lessons learned, customer satisfaction, and benefits achieved (vs expected) for the purpose of transforming yourself and the customer for the better. This includes guiding the customer to help them achieve maximum results with the product or service delivered, and laying the groundwork for their continued success.

Now that I have the framework locked in, I'll complete the model around these four phases. I am absolutely convinced that this model can help increase customer satisfaction and the general success rates of projects.

Project Planning Not All It's Cracked Up to Be

OK, everyone relax, I haven't lost my mind. Of course planning is important. But, as I've been saying for years, circumstances change the minute a plan is put on paper and a good project manager needs to expect uncertainty and know how to deal with it when it arises.

There's a great article in Projects@Work by Roger Bly that supports this approach. Bly talks about how project managers must manage the entire end-to-end process, and recommends taking a collaborative approach, using tools that enable frequent two-way communication and the ability for resources to keep the plan current and reflective of reality (something I completely agree with).

Here's an excerpt...

"A collaborative project execution application can make this process a reality in organizations of all sizes by allowing project teams to successfully tackle multiple concurrent projects. Projects are no longer constrained by static plans produced and updated only by project managers.

A project execution approach also frees project leaders from the mundane work of updating project plans, collecting progress information and reformatting information into status reports. Project plans can be collaboratively built and updated by the project team, often by reusing collateral, deliverables and templates from previous projects."

Far too often, a project manager will create an elaborate plan, and struggle to keep it current, ignoring the real issues that occur during project execution. If the team is trained to contribute frequent updates of remaining time (and any changes to the plan), the project manager can spend more time leading and monitoring as opposed to administrivia.

Of course, another easy way to accomplish this is to update the plan and percent complete collaboratively at a weekly meeting on an overhead projector, but it's ideal if the resources can update their own activities electronically.

For more about the need to focus on execution and communication, read the full article...

http://www.projectsatwork.com/content/Articles/231152.cfm

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

PMO Charters

Jerry's post about PMO success and failure experiences reinforces the point that it's essential to have a clear plan for what a PMO is intended to achieve. With that goes the requirement for all the usual requirements for a successful project - one to set up the PMO. What is it for, how will it be funded (from 5 to 15% of an enterprise project resources), where it will fit in the organisation. The charter for a PMO needs to be comprehensive.
The templates at the CVR-IT link below include a link to a PowerPoint presentation outlining PMO charter considerations.
Index of Project Templates

Project Goals and How to Achieve Them

Sometimes answers come from the strangest of places. I've been reading Jeffrey Gitomer's excellent Little Red Book of Sales Answers, which went to #1 on Amazon.com this week. There are many eye openers, and more than a few tips that project managers can benefit from as well.

For instance, here's what he has to say about the 3.5 reasons why people don't achieve their goals (by the way, he defines a goal as "a dream --- with a plan and a deadline")...

1. Failure to write your goals down and post them in plain view.

2. Failure to make a plan to achieve the goals.

3. Failure to commit, or live up to the commitments they made.

3.5 Failure to make goals that were achievable in the first place

I can say with certainty that every one of these are critical. Many people don't put goals in writing, nor do they develop a plan to achieve their goals. And even if they do, it's not always a realistic plan that considers all the angles.

With projects, like anything we're trying to achieve in life, we must begin with the end in mind. Or, as someone else once said, "If you don't know where you're going, you're probably not going to get there."

The book is chock full of simple formulas like this, that are useful whether in sales, project management, or in life.

PS: See my post from April 8th, Project Managers; Secret of Success Found, for a neat little story about JP Morgan. I think we have a "keep it simple" theme going here.

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

Project Risk Control vs Innovation

Winston Churchill once said, "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity."

As project managers, we are taught to focus on reducing or avoiding risk, but all too often we forget that a good risk management plan should include opportunities as well. Sometimes those opportunities will carry additional risks, but if the benefits are worth it, we need to exploit those opportunities. Certainly we can---and should---try to mitigate the risks, but the point is that in focusing on the dangers, let's not overlook the opportunities.

When framing a project, it's important to see for ourselves what the customer's situation is, and get engaged an an "opportunity assessment." As Tom Kelley of IDEO pointed out in The Ten Faces of Innovation, Henry Ford said that if he'd merely asked customers what they wanted, they would have said a faster horse.

Of course, not every opportunity will make it into the scope of the initial project, but at least there can be a plan to exploit it.

So, using Winston Churchill's axiom, should project managers be optimists or pessimists? I'd venture to say we need to be a little of both, and the right balance is the art of project management. For more on how innovation and project management can and should coexist, stay tuned for my upcoming post on the relevance of Tom Kelley's book to project managers.

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.

ERP Projects: Do Not Assume ...

With so much at stake with ERP projects, be careful about the assumptions you make. Les Johnson explores the assumptions that need better clarification and shared understanding before undertaking IT projects. ...

... "These words came back to me recently as I reflected on our ERP project delays and realized how many assumptions my team had made along the way. Assumption 1: That despite signs to the contrary, we could carry on according to the plan. " ...

ERP Projects: Do Not Assume: Via SearchCIO: When CIOs assume, they make...trouble?

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

Scrum Project Management - 3 Basic Questions

Scrum employs the dreaded daily meeting. The purpose is to keep everyone focused on the RIGHT work. A daily focus helps to manage the "overwhelm" factor.

Scrum asks 3 basic questions:

1. What have you done during the last 24 hours? (Progress, work completed to date)
2. What do you plan to do in the next 24 hours? (Forward planning, work you are about to do)
3. What is stopping/delaying you from getting it done? (Issues and risk management)

Whether you Scrum or not, have you asked your team members these questions lately? Do you ask them daily? Especially if your project is a "fixed time" project, I suggest you employ the daily meeting (doesn't have to take long at all!) and start asking those questions!

For more on Scrum see also Methods & Tools Articles Archives in HTML

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

Handling the Project Sponsor from Hell; Focus on Benefits

I've been posting recently about the fact that many projects fail because of the project manager's inability to defend the right plan to the executive sponsor. Here's a great article from 4PM about how the fictional (I hope) Chris Pimbock faces an executive sponsor who rattles off a bunch of demands and absolutely insists on an arbitrary deadline of October 30th. It's like something out of Dilbert.

Not wanting to head into a project death trap, Chris goes on to steer the conversation toward finding the ultimate problem being addressed, as well as what business benefits can be measured. He suggests a phased approach, solving the most critical problems first, and developing a sensible plan for getting there.

This is really the ideal way to address situations like this, and has been proven to be most effective. The other key is to recognize the difference between a desired target date and a hard deadline. Speed is important, but so is planning. Otherwise, we don't have speed---we have haste. As General George S. Patton said "Haste is speed without planning."

For an entertaining and informative read, check out the 4PM article. Please note: It's in PDF format ...

http://www.4pm.com/articles/pmtalk4-15-99.pdf

For more on how to deal with mission impossible situations, read Ed Yourdon's Death March.

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

Earned Value Management Deadline Looms for U.S. IT Projects

The Office of Management and Budget (OMB) has given government agencies until December 31, 2005 to develop a a plan for implementing Earned Value Management (EVM) for all of its IT projects. The IT industry in general has been slow to adopt EVM, and this is especially true in government agencies.

To assist with this, the CIO Council released a framework earlier this month for organizations to use for implementing EVM.

As reported on Government Computer News, "The guidance comes after a recent report by EVM software developer Primavera Systems Inc. of Bala Cynwyd, Pa., found that many agencies will struggle to meet the upcoming milestone because many agency senior managers have not embraced the concept. "

I think that's true for many senior managers in general, not just in the government. With the deadline a day away, let's hope the template has been of assistance. Meanwhile, check out the information below about the CIO Council's framework for implementing EVM.

CIO Council releases guidance on EVM plans

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

Results vs. Process - Revisited

The other day, I posted a blog on results vs process. The conclusion I came to was that for projects (which are by nature of limited duration), it was more important to do what it took to assure good results than to blindly follow process.

Of course, the definition of "good results" must be agreed upon. I also added the caveat that this does not apply to processes that must be observed to assure adequate results.

While I still fully believe this approach is true as a guiding principle for project managers, I've come across two good arguments in defense of process in general:

1) Results are often uncontrollable, while processes (if maintained) can at least assure more consistent results over the long haul. Uncertainty is a given, and good processes will allow for that and plan for that.

2) Conflict should always be expected, and should be used to improve processes rather than be seen as an impediment to results. Conflict is a good thing. Unresolved conflict is not.

My clarification of "results over process" is this:

• When defining processes, don't make the processes so heavy and bureaucratic that they impede results.
• Introduce processes slowly. Don't expect overnight results; Follow a maturity model and strive for continuous improvement.
• Relentlessly search for less invasive ways of accomplishing control.
• For each potential new process, use the"Five Why's" (asking "why" five times until you determine if the process in question is really needed). If in doubt, don't add it.
• Allow room for people to make decisions. If a principle will work just fine to help keep people on course, then don't institute an unnecessary process. Not everything can or should be "process-ized." Generally, aim for principles over processes wherever possible.

I do think Toyota has it right. By focusing on long-term results (i.e. continuous improvement) over short term results, continued success is more assured. By we don't want to unnecessarily impede short term results either. We can walk this balance by keeping our processes lean and giving project managers the freedom and confidence to do what is right to successfully deliver a project. People are ultimately our best asset.

Project Planning Tip: Facts are More Important Than Theories

When planning your project or solving a problem, always remember that facts are more important than theories. This means that agile approaches, rolling wave planning, prototyping, etc. should be used where appropriate, in order to base decisions on facts. The alternative is to plan all future phases in detail up front, which is tantamount to basing your decisions on pure theory.

Likewise, the project approach itself should be based on a visit to the customer to see how things are currently done, and get a true understanding of what is needed. Often, what's really needed isn't what is stated in the project request.

In A Scandal in Bohemia, Sherlock Holmes (by way of Sir Arthur Conan Doyle) said, "It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

This is sage advice for project managers as well.

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 Baby Steps; Start Simple

One of the biggest mistakes organizations do when trying to roll out project management practices is start with a big-bang approach. Project management success does not happen overnight. Best to start with a good set of values or principles, and very lean processes.

Have you ever seen people on the dance floor who recently learned to dance? They're so busy looking at their feet and counting that they forget to have fun and feel the music.

Same thing with learning the guitar, which is probably an even better example. Better to start by learning some simple chords, so you can start playing some tunes and feel good about accomplishing something (in my day, everyone started by learning to play Neil Young's "Heart of Gold"). Then you can learn theory. In fact some of the best players never even learned theory or "playing by the rules" (including the Beatles, Crosby, Stills and Nash, and others). Boy I'm dating myself.

It's the same with project management. Understand the principles first. Learn some basic lean processes (i.e. solve the problem, define the goals and requirements, document the scope, develop a plan... you get the idea). Then learn all the methods and rules for your toolbox.

Then break all the rules and focus on results and passion. Same as playing the guitar.

Leadership Equation: 12 Priorities to Live By

As PMThink regulars might know, I've posted several times about my key two priorities when managing project constraints;

1) Speed is more important than Cost
2) Success is more important than speed

Well, I have ten more overall leadership priorities that I live by. I didn't invent them all (some I've come across over the years and adopted, and some are even cliches by now), but these are the priorities that have served me well. I'll list them now, but I plan to write more about them in the future. Here are the other 10 priorities:

3) Principles are more important than rules
4) Results are more important than process
5) People are more important than results
6) Spirit is more important than ability
7) Experience is more important than spirit
8) Character is more important than intellect
9) Perception is more important than reality
10) Simplicity is more important than perfection
11) Integrity is more important than popularity
12) Facts are more important than theories

Chew on these for a while. More to come.

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 Software Conference: Primavera ...

Project Management Software Conference: Primavera: More than 40 Partners To Exhibit at Primavera Annual Conference: Via Primavera, Project and Portfolio Management

... "Primavera Systems, Inc., announced that 41 of its partners will exhibit at the company's 22 nd Annual Conference taking place November 13-16 at the Walt Disney World Dolphin Hotel in Lake Buena Vista, Florida. The event, one of the largest of its kind, expects approximately 1,500 attendees, and is a major educational forum for individuals involved in project, portfolio and resource management. " ...

Primavera is the largest independent provider of collaborative resource, project and portfolio management solutions. Primavera's world-class software and services are used by Global 2000 companies to choose the set of projects that best enable their strategy to plan, control and govern the chosen projects, and to accelerate the delivery of high-quality results for themselves and their clients.

Project Management "Storyboarding"; A New Way to Plan?

Sometimes, ideas come from the strangest of places.

A few years ago, while storyboarding a screenplay idea (which I still have waiting in the wings as a future project), I came across a piece of software that I realized could be equally valuable in project management. It's called Writer's Blocks.

It's sort of an electronic version of the "Cards-On-The-Wall" approach used by project managers for network diagram sessions. Since using cards on the wall doesn't work when your team is virtual, this could be an interesting alternative in those cases. It's extremely intuitive and allows you to capture ideas along with notes, move them around in different sections, link them, etc.

Alternatively, it could be used to actually "storyboard" your project, offering much more elaborate text than just a few words on a card. Certainly worth further exploration. I posted this find (along with Mind Manager from www.mindjet.com) on Edward Tufte's forum on information presentation. It's in the project management thread - which has incidentally been running for four years - possibly the longest thread in history.

Meanwhile, here's the link to Writer's Blocks.

Writer's Blocks 3 Writing Software

Top 10 Project Management Quips

It's not quite David Letterman, but here's a top 10 list of project management one-liners, selected from office-humour.co.uk.

1) If everything is going exactly to plan, something somewhere is going massively wrong.

2) Everyone asks for a strong project manager - when they get them they don't want them.

3) A project is one small step for the project sponsor, one giant leap for the project manager.

4) Some project finish on time in spite of project management best practices.

5) The person who says it will take the longest and cost the most is the only one with a clue how to do the job.

6) The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression.

7) The bitterness of poor quality lasts long after the sweetness of making a date is forgotten.

8) What you don't know hurts you

9) A change freeze is like the abominable snowman: it is a myth and would anyway melt when heat is applied.

10) You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.

For more of these, see the link below...

Jokes, Photos, Funny Stories and Office Humour - office-humour.co.uk

Business Strategy: Align Objectives and Execute

IBM launches new software that enables workers and managers throughout an organization to align their personal and departmental objectives with business strategy and drive execution of their workplace activities ...

Business Strategy: Align Objectives and Execute: Via IBM: IBM Software Helps Employees at All Levels Align Their Objectives With Company Strategy ...

... "According to feedback from IBM's customers and partners, more companies are recognizing that while they have lots of data and a sound business strategy, the execution of the strategy needs improvement. IBM Workplace for Business Strategy Execution helps employees understand their company's strategy in concrete terms, focus on what is important, and remain current on status and risks. A department leader can use IBM Workplace for Business Strategy Execution to clearly communicate team objectives and how they fit into the company's strategy; link to and monitor internal and external dependencies that could affect the ability to reach objectives; track progress toward the objectives though intuitive scorecards and dashboards; and initiate actions to correct gaps in performance. " ...

PMThink references on strategy and alignment:

• Achieve Strategy Execution: Accelerate Plan Funding Support


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


• Business IT Alignment: Business-Relevant Metrics


• Business IT Strategy: Successful Alignment


• Governance Alignment: Project Portfolio Management (PPM)


• IT Alignment: Cost Benefit Analysis ...


• IT Governance: SAP ESA Strategy


• IT Strategy: Motorola Exec Podcast ...


• ITIL: IT Service Catalog: Alignment Focal Point ...


• Microsoft Framework: Business IT Alignment


• PMO Role: Align Business and IT ...


• Project Failure: A Success Strategy


• Project Management Strategy Integration Conference December2005


• PublicSector CIO: Enterprise View IT Strategy


• Software Aligns Project Management With Enterprise Strategy: Enhanced Portfolio Analytics ...


• Strategic Alignment: Project Portfolio


• Strategy: Visualize the Design ...

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)

More Project Management Equations; The Triple Constraint Override

With nearly 30 years in IT, I've come across pretty much every situation, whether it was managing commercial software product development, acquisitions and divestitures, systems conversions, you name it. And over that time, certain things jump out as tried-and-true principles.

One of them I call the triple constraint override. That is, irregardless of the usual triple constraint of time, cost, and scope (I won't get into the other four possible constraints), I have my own principle that overrides all that.

It involves two simple equations:

Speed is more important than cost.
Success is more important than speed.

In other words, if we act fast, cost will usually follow naturally. Delays can increase cost exponentially, whether it's the cost of lost opportunity, the cost of reduced momentum, or any other number of costs associated with the risks of delay. Sometimes, it might appear that we're spending more money by rushing (such as paying a little more for a service rather than waiting to get the best deal), but in the end, what is really saved by waiting? I argue that there are hidden costs in waiting that can negate any gains.

But even speed must take a back seat to success. Notice I didn't say quality. That's because it's not about perfection. It's about the success of the project, whatever you take that to mean. If speeding things up risks the success of the project to the point where there's a 50% chance or less of success, then the speed has turned into haste and it's a sign to slow down and develop a more realistic plan.

Like any rule or principle, there are exceptions, especially during some negotiation situations. but we must consciously make that decision after weighing the situation against the two simple equations I've mentioned.

Just something I thought I'd pass along.

Planning for Project Initiation

Here's another of those questions that comes up during consulting engagements, particularly those where resource planning is an important management process.
Many organisations have a formal point at which a project is recognised as being part of the portfolio. Once a project is recognised as being official in this way, then it gets general visibility - it will have a name, perhaps a reference number, a project manager, a charter, a budget, a place on the executives regular status report, etc.
Frequently there is some kind of gate meeting for those organisations that use a Stage Gate Process. For others there may be a portfolio review committee or perhaps it's as 'simple' as getting three separate VPs signatures. Whatever the method, a common requirement is that there must be supporting information giving some kind of cost benefit analysis and, usually, more detail on probable timing, resource requirements, risk assessment and so on.
This information takes time, effort and resources to prepare. And there can be a lot of time, effort and resources involved. The issue is how does one plan for it when, technically, there is no project. There are three general approaches. Which one an organisation uses depends on its management and accounting practices and priorities.

1. Start tracking the project from the time of very first idea. Once it becomes 'official', there needs to be a way to include the effort spent in preparing the proposal in the newly approved budget - including the cases where the project gets rejected at the first gate. This approach would be relevant where the organisation is really interesting in total product costs. The problem is that there is no official plan at the outset against which time and costs can be recorded - and this makes resource planning difficult.
2. Have a specific proposal preparation project with it's own budget and approval mechanism. This would be relevant for major projects and often fits in the context where each phase of a major project would have it's own methodology, plan, budget and approval mechanism.
3. Have a pseudo project which covers 'early project activities' with resources and budget to do a range of relatively lightly defined activities. In this case there would be little formal connection between the effort for the early project proposal effort and the eventual full project. This approach would be suitable for an organisation where project proposals are fairly simple and the effort required for an individual proposal can be approved under a fairly large umbrella.

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!

CIO Value Measurement: European Market Alliance ...

CIO Value Measurement: European Market Alliance: Alinean and Birchman Group Form Joint IT Value Measurement Venture for CIOs: Expands Alinean’s European Presence ...

Alliance in European market will drive CIO value measurement services ...

... "The Birchman Group’s proven service offering, supported by Alinean, allows the company to deliver large and tangible benefits to its clients by quickly and accurately aligning IT with business objectives, often a time-consuming and painstaking task. The Alinean ROI Analyst Enterprise has significantly improved the quality of The Birchman Group’s analysis and the time-to-delivery. The Birchman Group assists customers in gaining maximum benefit from technology investments through strategy development, business case development, program management, benefits tracking, process improvement, change management and other IT Value Management services. " ...

From business strategy to successful IT solutions, The Birchman Group provides completely independent expertise in planning, executing and deriving business value from IT programs. Pioneering the IT Value Management approach in Europe and South America, The Birchman Group can assure that corporate IT spending is balanced between support and innovation, is aligned with business goals, is formulated with reference to corporate peers, is comprehensively program-managed and delivers according to fully risk assessed plans. The outcome ensures that the IT department becomes a stable and consistent business value generator. With global reach The Birchman Group has enabled blue chip organizations to realize strategic intent by building complimentary and cost effect IT strategies; comprehensively assess, plan and manage a suitable and significant portfolio of Return On Investment (ROI) and Total Cost Ownership (TCO) justified programs measured by business outcomes; and deliver these programs utilizing the highest caliber Birchman program and project expertise. Established in 2003, The Birchman Group has grown rapidly to more than a 100 employees in five countries, which reflects the success of IT Value Management as a service offering and the demand from organizations for The Birchman Group’s unique set of services and resources.

Alinean develops software tools to prove and improve the value of IT investments. The company’s founding team pioneered the concept of interactive ROI and TCO software in 1994, developing award-winning solutions for leading IT vendors and consultants. Its research methodologies and software tools are used by analyst firms, vendors and enterprises, and have helped justify billions of dollars in IT spending and derived value.

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).

IT Research Projects: Google, NASA Join Forces

Google and NASA have agreed to collaborate on research projects that will synergize the knowledge of both organizations. Between Google's ability to organize information and NASA's supercomputing ability, some interesting advancements should result.

Check out the Computerworld report...

Google, NASA plan R&D partnership - Computerworld

Process Change or Process Tool First?

Process Change or Process Tool First?: Via Optimal Friction: Tools Stimulating Change ...

We have been on both sides of this debate. Historically, more often implementing the process-enabling tool as a catalyst for process change (with a limited success rate). Michael Mah expresses the concept of flexible tools pacing the cultural / process change in a friendly way. I like the sound of that friction ...

... "It's even better when a manager can prepare a project plan using their way, then having the tool recreate that plan, essentially cloning it, and extending the plan by offering a benchmark of say, the deadline, against industry, or deriving the implied productivity. " ...

Transformation Project: Work Plan and Tasks ...

Transformation Project: Galvin Electricity Initiative

Transformation project with work plan and tasks ...

... "The Galvin Electricity Initiative officially announced its mission to create an actionable blueprint for transforming the U.S. electricity supply and service infrastructure into a resilient and adaptable system that can perfectly meet the needs of the rapidly evolving digital economy and society. The fundamental principle guiding this Initiative is that raising the quality of the nation's electricity supply system will create substantial cost savings for all consumers and society at large. ...

The project work plan, including descriptions of the project tasks ... " ...

MultiProject Critical Chain System ...

MultiProject Critical Chain System: Via Realization Technologies: Leading Organizations Share How They Are Doing More Projects Faster Using Critical Chain Project Management: Realization Technologies’ Execution System is Key to Outstanding Successes

Execution using Goldratt’s theory of constraints / critical chain methods enables doing more projects faster ...

... "He (Dr. Ajai Kapoor) also stressed that customers in the process of implementing should follow eight easy steps to mirror the fast implementation times and results of successful organizations.

1. Analyze and create management consensus on business needs.
2. Get buy-in on the improvement potential.
3. Get buy-in on the 3 Rules and set ambitious targets.
4. Design the solution (project architecture, processes and policies).
5. Create a pipeline plan and validate it.
6. Establish task management.
7. Establish surrounding processes.
8. Continue improving using the Theory of Constraints and Lean. " ...

Realization Technologies defies conventional wisdom, both business- and product-wise. Used by over 135 leading organizations throughout the world, its Multi-Project Critical Chain system, based on Critical Chain and Lean principles, breaks old management rules instead of blindly automating them. Unlike traditional project management software that is heavy on planning and tracking, this system changes the rules of execution. Realization also offers fixed price implementations, with 90 percent of its fees tied to improving customers' bottom lines. Realization is headquartered at 2 N. First Street, San Jose, Calif. 95113.