G-Cloud Project

Government leaders are looking to the cloud computing model as a means to leverage their IT applications investment, so that over time a robust application portfolio is available to the community. ...

... "Development of G-cloud is to be made a priority, according to the Digital Britain report, and while the plan is developed over the next three years, all other IT services procurement should look to follow a similar model in preparation. " ...

Via UK Computing: Government app store

Improvement Plan

Is continuous improvement better than one decisive action? Too many companies are waiting until external threats become reality before they commit to an improvement plan. ...

... "Now that its independence is at stake, it is taking decisive actions. It may not work because the plan probably comes too late. " ...

Via BloggingStocks: Anheuser-Busch

CRM Projects: Stick to the Basics

Position yourself for success in the customer relationship management space. Do the project management basics - build a case, detail the plan, and check a few performance indicators after the implementation stabilizes. ...

... "Of respondents that have created only a project plan, 50% reported a successful implementation, 60% of those that did an ROI analysis reported CRM success, and 70% that did a post-project review saw success, according to the survey. " ...

Via SearchCRM: CRM business success

Practical Application of Innovation

Here's practical advice on applied innovation techniques. ...

... "Any Innovation plan must be just that, a hard plan. It can't be an initiative. A plan has to have milestones and expected results. These results must be measurable and memorialized in writing. " ...

Via The Heart of Innovation: Science of Innovation

Steer Your Plan

Business planning requires routine schedule updates. Sound familiar? ...

... "Set up schedules for frequent review. Your plan will change. Your assumptions will be wrong. Your plan will be wrong. " ...

Via Tim Berry, Huffington Post: Business Planning

Business Plan Sets Agenda With Stakeholders

Insights on using the business plan (or case) to get stakeholders aligned on measureable objectives and keeping dynamic story updated. ...

... "A business plan is a way to coordinate, communicate, and collaborate with accountability and tracking. It should get all the key people on the same page. Nobody can execute a plan they don’t know about. " ...

Via How to Change the World: How to Write a Business Plan

IT Strategy Is On Board-Room Back-Burner

Deloitte survey provides insights into boardroom perspectives on IT strategy. While boards don't have more time to focus on IT strategy, the limited time available should be used effectively. ...

... "But they don't plan to work toward improving the strategy: 52 percent said their board won't spend any more time on IT over the next three years than it does now. " ...

Via CIO: Board Perspectives on IT

HR and IT Collaborate For Successful Change Management

HR and IT have areas of synergy that contribute to successful projects. The workforce and key talent have a special role in embracing organizational change. ...

... "If successful, the plan will produce a community of people who understand the reasons behind the change, the impact on their roles, and their role in the success of the transition. " ...

Via SMBedge: HR and IT Collaborative Success

Project Management Delays Are Sometimes Good

There's an interesting article on Computerworld about the need to procrastinate more in project management.

Huh? No, really. In reality, it's about slowing down the early stages of a project in order to get the true client needs and requirements understood and prioritized. It also suggests procrastinating by moving some complex items later in the plan to accomplish some quick wins early.

Maybe good things really do come to those who wait.

How to Manage by Procrastination

Innovate: Monday Morning Plan

Here's some ideas to jump-start your innovation tommorrow (Monday). Make some time for brainstorming. Don't penalize mistakes. Get folks interacting. Read on. ...

... "Creative or alternative thinking does not mean playing with brightly coloured balls all day long. It means selecting appropriate techniques and methods from as wide a variety as possible and matching them to the task in hand to get the best results possible. " ...

Via Derek Cheshire's Creativity and Innovation: Monday's Plan of Action

Project-Lessons-Learned From Walter Reed

There are more lessons to be learned from the experience at Walter Reed, but here's a good one ... sustaining quality (of service and infrastructure) in the face of closure. If you haven't already, you may be faced with a project to dismantle, decommission, or divest part of your organization. Be ready for this situation. ...

... "When we plan to shut down an operation, the longer the lead time between decision and action, the more discipline we have to apply to making sure that that operation is not victimized, directly or indirectly, by our natural instincts. " ...

Via Snohomish County Business Journal: Lessons

Project Sabotage

If you wanted to sabotage a project even if leadership showed support for it, what would you do? Leadership support is necessary, but not sufficient. Look out for these signals. Have a strong change plan than purely compliance-driven, unless absolutely necessary. ...

... "Confuse meetings with plausible, but pointed, questions. Be too busy to do what's expected of you, e.g., fail to supply data or other resources. Or send a subordinate in your stead " ...

Management Support: Panacea?

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

The Enemy of Simplicity: The Thud Factor

We've all heard about the benefits of simplicity, whether in our processes, our communication, or in our objectives. In all its forms, simplicity is a way to reduce confusion, boost morale, and encourage speed and flexibility. In fact, simplicity, speed, and flexibility are three of the "Six Winning Principles" I wrote about in Napoleon on Project Management (the other three being exactitude, character, and moral force).

But there's a lurking enemy of simplicity, and it often goes unnoticed. It can be found in the motives of individuals creating the processes, communications, or objectives. I'm talking about job protection. I don't mean the blatant kind that results from grandiose thinking, egotism or turf wars. It's much more subtle than that.

It can happen if an individual or department is placed in charge of creating a process or devising a plan. Or it can happen if a consulting company is brought in to do a study or offer advice. Common sense says that these people, while not necessarily devious, will hesitate to come up with anything too simple, lest they feel they're not doing their job. The result is often something that is way more detailed, complex, and expensive than it needs to be.

What can we do about it? We need to be very aware of motives and rewards, and make sure we don't consiously or unconciously reward people for complexity. We need to send a message that the shortest, simplest way to meet the goal wins (even offering incentives if possible). This can avoid what many consultants jokingly refer to as "the thud factor"----the customer's perception of the value of the service as judged by how much of a noise the report makes when it's dropped on their desk.

Whether it's a consulting company, a PMO, an internal process center, or a project team, we need to find a way to head off the thud factor and insure simplicity. We can do this by understanding motives; sending the right message; insisting on brief, simple reports; and creating the right reward system.

Just the Facts: Evidence-Based Management

I recently read an enlightening book by Jeffrey Pfeffer and Robert I. Sutton, titled, Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management.

The premise of the book is that many organizations follow the guru du jour, or manage according to the book of "someone said so." As the book points out, if we only looked at the evidence, we'd see that may of these so-called truths are anything but.

Here are some examples of the lessons the book has to offer, always supported by evidence:

1) Forced ranking of employees doesn’t work, especially where people’s performance depends on interdependence with others. Furthermore, a survey of over 200 HR professionals by the Novations Group found that forced ranking (employed by more than half of the companies) resulted in lower productivity, injustice, skepticism, less employee engagement, reduced collaboration, lower morale, and mistrust in leadership.

The authors add that, if an organization trains people right and places them in an effective system, there’s no reason why 10 or 20 percent would automatically become incompetent every year.

2) Beware of your biases as a manager. Studies of NBA drafts showed that players picked earlier and paid more were less likely to be traded and had longer careers, regardless of their actual performance.

3) In the war for talent, don't forget that bad systems cause far more damage than bad people. Try redesigning systems and jobs before judging individuals. And don’t give people objectives unless the system and staffing can support it.

4) Watch out for dangerous incentives. One organization's salespeople shipped too far ahead of schedule just to win a prize. Some salespeople would hold customer returns in the trunk of their car so they still get their commission for that period. Others opened bad credit accounts because any order counted as a good order. In another company, incentives to complete truck routes early led to increased accidents and overloading of trucks to avoid multiple trips.

5) Strategy isn’t all it’s cracked up to be. Operational execution often has a greater impact on performance. The CEO of Wells Fargo once said, “I could leave our strategic plan on a plane and it wouldn’t make any difference. No one could execute it.” In U.S. football, virtually every play is designed to go for a touchdown. Unfortunately, reality gets in the way, as do mistakes in execution.

The authors point out that time spent pursuing strategic options could be better spent solving operational problems or focusing on customer needs. Organizations such as eBay and Intel use a “learn as you go” approach, putting something in the market and tweaking accordingly. Doing the right things is important, but not at the expense of doing them effectively.

6) Many changes, including mergers and acquisitions, ERP implementations, Six Sigma programs, Business Process Reengineering, cost cutting initiatives, and others, carry risks that outweigh the benefits and can be easily misapplied. People tend to underestimate the costs and overestimate the gains.

However, if it is determined that the change is still needed, the authors suggest we:

a) Ensure dissatisfaction with the status quo (i.e. the burning platform)
b) Communicate the same message repeatedly about the need for the change
c) Express extreme confidence in the change, but listen to concerns and adjust accordingly
d) Expect setbacks, errors, and miscommunication; Learn from it and revise processes. Never point fingers.

7) Based on proven evidence, in order to gain respect and trust, leaders should:

a) Act "as-if" - Be sure to act and talk like a leader
b) Have some sense of modesty. Understand the difference between knowledge (knowing things) and wisdom (knowing what you know and knowing what you don’t know).
c) Know when to get out of the way.
d) Above all, be an architect of systems, teams, and cultures.

These are but a few of the valuable nuggets in the book. The book offers additional tips as well, plus loads of supporting stories, examples, and research. Perhaps most valuable is the chart on the various types of changes and risks associated with them. I highly recommend this book to all leaders.

IT Project Consideration: Data Center Power Consumption

Hardware, software, internal and external labor go into any analysis of IT project investments. The impact of new hardware investments on the data center power consumption needs to be considered in order to plan cooling and energy capacity requirements. ...

... "Power and thermal demands are changing drastically within server rooms, he says. Any IT project these days has to consider heat density as an important factor. " ...

Data Center Energy Consumption

Getting to grips with Project 2007

Microsoft Office Project Server 2007 - to be formal about it - has been on the price list and RTM (Released To Manufacturing) for nearly three months now. And it's still hard to find definitive manuals or books about how to configure and use many of the new features. There have been a number of white papers and promotional documents released. These typically address technical installation (up to a point) and quite a lot on the server side architecture.
But best practices for how to use the new time sheet feature, reporting the new budget category costs, using the new resource plan feature and so on are elusive.
Most information is being spread through blogs, such as Microsoft Office 2007 Project Blog and discussion groups.
Microsoft does offer courses which are loosely described as 200-300 level. Information on these can be found at the 'EPM University'. The curricula for the two courses offered at the moment do not look as though they answer the Best Practice questions. For now the best source is still individual experience!

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

CIO Focus: Replenish Talent, Plan Succession

With the perfect storm of aging demographics heading toward us, CIO's need to assess their talent, plan for career development of their staff, and create a map for succession. ...

... "Top of the list is the need to address the imminent loss of senior members of IT departments. With many CIOs due to retire in the next few years there will be a huge loss of knowledge and wisdom ... " ...

Via Silicon.com: Link

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

PMI Announces Program Management Certification: Bring On the PgMP

PMI has finally announced the certification for program managers ---- the Program Management Professional or PgMP (the "sm" after the designation in the press release is for the service mark). It'll be available in early 2007.

The title is probably a good choice and has good synergy with the existing PMP designation. Of course, it's the same designation as the Program Management Plan (PgMP) from the Army Core of Engineers, so hopefully that won't cause confusion in those circles.

As I've mentioned before, the rigor of the PgMP requirements should give organizations a pretty good feeling about taking on program managers with this certification. It's based heavily on experience in the real world and feedback on results as opposed to pure knowledge.

Also, one needn't have a PMP certification to apply for PgMP certification. Here's the press release...

PMI to launch credential for program management practitioners

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

Talent Management: Readiness Survey Results ...

Interesting results of recent talent survey ...

Knowledge Infusion performed the 2010 Talent Readiness Survey in the early summer of 2006 to understand the talent gap to be left by retiring Baby Boomers. The study evaluates when people will leave the workforce, if there will be talent shortages that impact business outcomes, the steps organzations can take to find, develop, and retain the critical skills required for success. ...

The survey validates these findings:

Larger organizations are likely to impacted the most by the retiring workforce.

By 2010, a significant portion of the eligible workforce will retire.

To get ready: You must understand the impact on your organization. What percentage of your workforce could retire in four years? If succession planning at your company is focused more on the executive ranks, now is the time to apply succession modeling to your critical skills. Take a skills inventory. Understand the skills across the workforce demographics. Develop a plan to attract and retain the critical skills for your organization.

And, of course, digitizing your talent data enables your organization to provide visibility to this critical workforce information. Cornerstone OnDemand provides integrated on-demand solutions for talent management.

Via Cornerstone OnDemand : Managing Talent in the Face of Workforce Retirement ...

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.

IT Strategy: Upgrades Align to Long Term ...

End-of-Life upgrades and capacity increase investments should align with the architectural roadmap generated by the IT strategic plan. Article discusses techniques to support upgrade decisions, postponement tactics, and repair/replace choices. ...

... "Any IT investment--whether it's an upgrade, a purchase or a lease--should support your long-term IT strategy. Otherwise, you're not spending your money wisely. " ...

IT Strategy: Upgrades Align to Long Term: Via Entrepreneur: Upgrading Your IT Equipment

IT Strategy: Domino's Rebuilds ..

New IT leader joins Domino's Pizza and plan infrastructure overhaul. ...

... "Domino's Pizza will revamp its IT infrastructure and introduce a new IT strategy, which will be spearheaded by a new company IT director. " ...

IT Strategy: Domino's Rebuilds:Via OneStopClick News: Domino's revamps IT infrastructure

IT Strategy: Enable Knowledge Based Economy ...

Government minister sees knowledge work as the key to economic development and creates IT strategy that supports the creation, collaboration, and deployment of knowledge to drive economic growth. The plan emphasizes the development of citizens to create and leverage knowledge to further innovation in the local and global marketplace. ...

... "Kuwait's Communications Minister Ibrahim Al-Shatti presented Monday a working paper outlining the national IT strategy in light of Knowledge Based Economy (KBE). " ...

IT Strategy: Enable Knowledge Based Economy: Via Kuna: Kuwait's Communications Minister outlines national IT strategy ...

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.

Collaboration and Openness Business Model ...

In continuation with previous post on collaboration and openness, IBM releases study that supports the business model for transparency and collaboration to drive innovation and, ultimately, revenue growth. ...

... "In terms of how to drive innovation, the study found that 76% of CEOs ranked business partner and customer collaboration as top sources for new ideas. This greatly contrasts with internal R&D, which ranked eighth as a source for new ideas -- cited by only 14% of CEOs. Despite the value they place on collaboration, many CEOs are still in the planning stage. While 76% of CEOs say that collaboration is critical, 51% say their organizations currently collaborate extensively. Interestingly, this is exaggerated in emerging markets, where 73% are collaborating, compared to 47% in mature markets. The study also suggests a link between collaboration and financial performance. " ...

Collaboration and Openness Business Model: Via IBM: Majority of Global CEOs Plan Fundamental Change and Expect New Forms of Innovation to Drive Growth, According to IBM Study ...

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

Earned Value: Government EVMS Progress, Targets Raised ...

OMB provides status update for agency progress against electronic government targets. Metrics show modest progress in adoption of earned value management system, EVMS. 2006 targets raise the bar to drive further adoption. ...

... "As of September 30, 2005, 28% of agencies have fully implemented EVMS (7 out of 25) and on average are achieving at least 90% of their cost, schedule, and performance goals. Another 52% of agencies are using some level of EVMS (13 out of 25) to track the cost and schedule status of their major investments and do not have cost overruns or schedule delays exceeding 30%. Those agencies are taking the appropriate actions, including developing comprehensive agency policies and incorporating requirements into contracts for using EVMS, to bring the management of all of their major IT development efforts into full compliance with the industry standard for EVMS. Together these two groups of agencies account for over 75% of Federal agencies being able to measure progress toward milestones in an independently verifiable basis, in terms of cost, capability of the investment to meet specified requirements, timeliness, and quality. The remaining six agencies have a plan of action and milestones to incorporate the use of earned value management into their Capital Planning and Investment Control Process.

For FY 06, the goal is for at least 50% of the agencies managing their IT portfolio in accordance with the standard and averaging 10% of cost, schedule and performance. " ...

Earned Value: Government EVMS Progress, Targets Raised: Via OMB: Expanding E-Government: Improved Service Delivery for the American People Using Information Technology ...