The Customer Perspective on Projects

#IT Fail - Defining IT Project Failure from Waggware on Vimeo.

Goal Setting

Setting your annual goals and objectives? Consider fail fast, fail cheap. Is failure your goal? Go ahead. Take some risk. ...

... "It's not stupid to have a stated goal of starting several ventures that will fail, or asking three stupid questions a week ... " ...

Via Seth Godin: The goals you never hear

Change Projects

IBM study validates the challenges associated with change projects and identifies actions that differentiate the leaders. ...

... "Rather than simply throwing money at the problem they invested in building awareness of project complexity, spending more on building change skills and developing their long term tools, methods and capabilities. " ...

Via IBM: Organizational Change Projects

FUBAR

A fun read of a sad, but all too often true, reality ...

... "Over the past two weeks, I've conducted confidential off-site group interviews with all of the ABC consultants working on the FUBAR project. " ...

Via Bruce F. Webster: Runaway IT project

Late Project Record?

G'day mates. ... Is this the record for late projects? Nine years late. ...

... "A COMPUTER program to streamline Victoria's criminal justice system is running nine years late and could cost four times as much as planned. " ...

Via Australian IT: Project is 9 years late

Failure Points to Navigate on Your Project

Avoid these failure points by planning, aligning with business objectives, leadership and sponsorship engagement, adapting to business conditions, and discipline scope management. ...

... "most failures come about, not as a result of the technology, but as a result of the management of technology, says Michael Krigsman of Asuret ... " ...

Via Baseline: 5 Points of Failure

Managing Project Failure Better

Vid explores project failure management techniques ...

Concurrent Projects: No Badge of Honor

Question: How many concurrent projects does it take to break the proverbial camel's back?

Answer: Less than you think.

I read in this month's PM Network magazine that project managers are lamenting the number of projects they're being asked to juggle, with the average number of concurrent active project at 8. I've actually consulted at some organizations where some project managers are loaded with 20 or more active projects (and these are real projects, some of them large-scale initiatives).

This is the surest way to guarantee project failure. Some managers might say that not every project requires conscious activity from the project manager at the same time (maybe that should be a new book, "The Unconscious Project Manager.") It's a poor excuse, and discounts the work that a project manager really should be doing. It virtually guarantees that the project manager will shortchange the communication (which should be 90% of a project manager's job), not to mention the appropriate risk management efforts and execution monitoring.

In most cases, here's what I feel the correct number of concurrent large projects should be for a given project manager:


Ready????


...calculating .... number crunching.....


And the answer is....


1


For each project added, reduce 20 to 25% of the project manager's effectiveness. It's possible to oversee a larger number if there are project managers reporting to you, but that's not project management; that's program management. And even then, only one program should be managed by a person at a time.

It's also possible to manage a few smaller initiatives, but much depends on the team members and their readiness level for delegation of work packages (without coaching, etc.). That should not be assumed without validating first. Having project administrators or coordinators can also help offload some of the administrative work.

There's no magic number for how many of the small-to-medium size efforts can be juggled, but project managers would be wise to seriously consider what it takes to manage each effort effectively (not to mention the readiness of their staff to own the work packages).

I've seen more project managers fail because they are unable to make a case for turning down additional projects than for any other reason (in some cases, it's because they themselves underestimate all the things they should really be doing during project execution). At the organizational level, lack of focus and a prioritization process is usually the root cause.

Not too long ago, I did a presentation to a room full of CIOs. During lunch, I asked them what they felt their biggest challenge was regarding project management. After some discussion, they agreed their #1 challenge was having to justify to the board why their organization should not take on additional projects (or why they should decrease their current project list). Even at the CIO level, this is an issue.

A few CIO's mentioned that they had some success by putting together a high-level graphical view of the top few initiatives, showing the major activities and groups that were involved. Apparently, this got the point across that there was more to the projects than the executives realized. Sometimes seeing is believing.

The lesson: Don't try to fight a battle on two fronts... and certainly not 20.

Project Early Warning System

If we can detect project problems early, we can resolve them. What's your best indicator? Scope quality, SPI / CPI, QA results? ...

... "In general, the earlier you spot trouble, the easier it is to do something positive about it - anything from making minor adjustments to scope or schedule to killing the thing outright. " ...

Via CIO: Project Rescue

Project Foe: Complacency

Complacency, or lack of accountability, is a root cause of project failure that proj managers need to be ready for. If it pervades the culture of an enterprise, watch out. Consider cutting scope way back and increasing phases to determine if performance can trend higher. Otherwise, cut your losses. ...

... "Despite the critical reaction to the piece, I'm still convinced that complacency – as evidenced by the recent Economist survey that found that over half of European IT professionals feel there is no risk to their job security if they do not hit project deadlines – is a major factor in the UK's appallingly high IT project failure rate. " ...

Via IT Week: Project Culture

Project Failure: Business Case Assumptions Faulty?

Don't be ashamed if you flubbed a business case or had a miss on an IT project. Your sin pales in comparison to this destruction of business value. ...

... "In 1998, Daimler paid $36 billion in stock to buy Chrysler. Yesterday, it announced a sale in which it's putting more money into Chrysler than it's taking out. " ...

Via Washington Post: Tow Job

Project Failure Brings Great Lessons

Andrew Makar has an excellent article on Projects@Work outlining key lessons from a prior project failure. I even like his tag line stating that he is "focused on effectively translating project management theory into actual practice." Indeed, that's where the real lessons are to be found.

It looks like it's part of a series---at least a two-parter. This one has lessons about defining clear roles up front, keeping the same project manager throughout the project, maintaining a "living schedule," prioritizing elements in project scope shoulud tradeoffs be needed, and establishing a clear change control process.

I couldn't agree more. Read on...

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

When Project Failure Impacts Enterprise Survival

One of the risks that we consider when preparing a business case for IT projects is business impact. It is a risk that is worth considering, understanding, and mitigating. Or else, this happens. ...

... "Samas, supplier of office furniture, will need to issue new shares as the company has been financially hard hit following an IT project. " ...

Via Expatica: Dutch News

From Samas Annual Report: "The implementation of project Harmony in the course of the financial year under review and especially in the year 2006 / 2007 may impact the business as a consequence of these changes. The company manages the risk through a phased implementation programme. "

Project Visibility and Transparency

Don't let doomed projects proceed in secrecy. Make the truth transparent and visible. Identify an action list to deal with the issues or prepare recommendation for cancellation. ...

... "The sad part is that often the people working on these projects know that they will fail, and yet, they are afraid to voice their opinion to the people in charge. " ...

Via Tom Peters: Doomed Projects

Results Project Failure Poll

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

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

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

Project Management Quotations

Here's a Wiki Quote site with a number of project management quotations. Despite some tired and well worn ones, there are a few gems in there, such as:

"The bitterness of poor quality last long after the sweetness of making a date is forgotten."

"Some projects finish on time in spite of project management best practices."

"The more ridiculous the deadline the more money will be wasted trying to meet it."

"The most valuable and least used phrase in a project manager's vocabulary is "I don't know"."

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

"The project would not have been started if the truth had been told about the cost and timescale."

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

"All project managers face problems on Monday mornings - good project managers are working on next Monday's problems."

"At the heart of every large project is a small project trying to get out."

"Everyone asks for a strong project manager - when they get him they don't want him."

"Good project managers know when not to manage a project."

"If you don't attack the risks, the risks will attack you."

Enjoy...

http://en.wikiquote.org/wiki/Project_management

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.

Benefits Realization Challenging: Europe Insurance Industry ...

Recent research (DataMonitor) shows that European insurance companies are challenged to realize the documented financial benefits forecast for their IT projects. Common experience or industry specific? ...

... "While insurers continue to embrace the use of return on investment (ROI) to measure IT project success and failure, many do not meet their own targets. " ...

Via Insurance Networking: Link

Unconsulting: Common Sense Lessons for Project Managers

At someone's recommendation, I just finished reading Unconsulting, by David Newman. Fascinating and energizing book for anyone in business.

His book is partly inspired by Peter Drucker's statement, "Only marketing and innovation produce revenue. All other business functions produce costs." To this end, Newman offers that "the bottom line is meaningless if the top line is weak." He points out that, according to studies, "Companies with the same earnings per share that got there from SALES were worth about 30% more than companies who got there with COST CUTTING."

Newman, who, according to the book's back cover, has been called "a younger version of Tom Peters with less hair," offers 95 common-sense "in your face" tips.

A few more key points, paraphrased from the book:

• When consulting, talk to people (especially the impact points such as customers, suppliers, etc.) to gain anecdotal data to gain texture, context, and perspective.
• 95 percent of problems can be addressed by making significant changes to 5 percent of the processes, people, or technology.
• Simplicity defined: Find the shortest way to the best answer.
• Be with the client, not of the client. Rock the boat. You're there preceisely for that reason and to give advice. You're there to do your thing for them, not be a "yes" man (or woman).
• There is no cookie-cutter. Don't sell canned solutions. Listen to the client and look at unique angles to each engagement.
• Bill Cosby says, "I don't know the key to success, but the key to failure is trying to please everybody."
• Don't isolate talent management and organizational development to one department. Institutionalize it in all your management.
• The unconsultant handles an engagement in this way:
  
  "I'll ask some questions, do some research, guide the discussion, help set clear and specific objectives for the work, offer options, tools and answers each step of the way, and then we'll do the work together."
  
  All in all, very refreshing stuff. And a good model for project managers as well. I highly recommend this book. It's not available on Amazon.com, only on Newman's site, but well worth getting. Also, see the wealth of free white papers on his site, as well as his blog...
  
  David Newman: Professional Speaker Motivational Speaker and Keynote Speaker and Business Consultant

Business IT Projects: ERP Implementations ...

Article summarizes key elements of successful ERP projects: committment, speed, scope management, empowerment, phased implementation with quick wins, data cleansing and standards, education and training. ...

... "So it is now perfectly possible to turn what might well once have been an unrewarding slog (likely to end in failure) into a structured project with manageable milestones and relatively quick wins for the business along the way. " ...

Via SciTech Today: Toward Better ERP Implementations

Major Project Failure: Lessons Learned

There's a good article in Computerworld from Michael Hugos about lessons learned from a major failure.

Three key takeaways from the article (which happen to ring true with what I've been preaching for years) are:

1) Have clearly defined goals and measurable objectives
2) Be sure to have one single leader driving the project
3) Implement in fixed iterations to assure quick wins, earlier benefits, and reduced risks

Here's the full article...

Lessons learned from a major failure

Project Failure: Asset Impairment Charge: IT Strategy Rationalization ...

IT integration projects are a tough business. Failures can be expensive, impact the bottom line, and affect careers. Here's a clear example ...

... "LCH.Clearnet has decided to close down its Generic Clearing System (GCS) project. A review of the GCS programme in 2005 had already concluded that part of the GCS investment would not be brought into economic use and an impairment charge of EUR20.1 million was therefore recognised in the 2005 interim accounts. Further work completed in June 2006 concluded that the further development of GCS was not economically or technically viable, and the Group has therefore decided not to continue to use assets from GCS within its technology strategy. An impairment charge of EUR47.8 million, which substantially relates to those assets, has been recognised and will be reported in the LCH.Clearnet Group Limited 2006 half year results to be published in August." ...

Project Failure: Asset Impairment Charge: IT Strategy Rationalization: Via LCH ClearNet: LCH.Clearnet Rationalises IT Strategy ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Implementing PPM: Don't Expect Overnight Results

Karen Klein of Projects@Work interviewed Daniel Stang, a principle analyst at Gartner, on preparing for Project Portfolio Management (PPM).

Some key lessons are to not expect overnight success, to implement in stages (beginning with automating what is already working), and to engage a good change management team.

Organizations that attempt to go from zero to high level maturity via a big-bang approach run a high risk of failure. Stang also cautions against trying to sell PPM initially on the hard benefits. The benefits at the early stages of maturity tend to be softer, with the tangible benefits coming later.

Here's the article. Also, see the free PPM Software Evaluation tool offered at the bottom of the article.

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

Project Measurement Framework ...

Article explores the transformation experience of AGEdwards where the project management success rate was improved, through leadership training, a measurement framework, and enhanced organizational models. ...

... "Ed Pilewski, now VP of IT productivity and quality, chose not to take the traditional route of forcing a rigid project management methodology on the technology staff - a tactic that can backfire and create resistance to change. Instead, he implemented a standard framework for measuring, monitoring and reporting on a project's progress that fosters transparency and accountability. " ...

Project Measurement Framework: Via CIO: When Failure Is not an Option

5 Lessons in Leadership

The following Lessons in Leadership were originally presented at a recent CIO Leadership Conference but are also applicable to PM's:

10. Failure is not an option (as per Apollo 13's project leader Gene Krantz)

9. The kind of organization you are in determines the kind of leader you need to be (I'd also add that WHERE the project is in its lifecycle and the level of project experience your team and stakeholders have also matters)

8. A good leader has integrity (e.g., accountable, truthful (including in how you report project status and metrics!), a team player and tough when needed)

7. Don't be lazy. (push beyond your natural abilities - get into the details, get out of your office and talk to people, etc.)

6. Make sure that everyone in your organization can articulate what it is you're trying to accomplish (I've also heard this called "the hymn" (i.e., make sure everyone's singing the same tune, from the same book); if you have a more PC, one-word term, let me know!).

You'll have to wait until later for the next 5...this was plenty to digest in one sitting.

Thanks to Abbie Lundberg, the Editor in Chief of CIO Magazine for the info and insights that she shared in the June 15, 2006 edition. They formed the basis for this blog.

Silence of the Project Managers

Have your stakeholders stopped screaming, Clarese?


As reported in Computerworld, a study by a Utah-based training firm found that the biggest cause of project failure is the inability of project managers to effectively confront management and key stakeholders on five major sensitive areas.

Here's an excerpt:

According to David Maxfield, director of research at Vital Smarts, the five
situations include the following:

• Setting arbitrary deadlines and inadequate resources that "set up a project to fail."
• Failing to provide the necessary leadership, political clout or energy for a project.
• Skirting or manipulating the project priority-setting process.
• An unwillingness by team members to support projects as required.
• Failing to acknowledge project problems until it's too late for remedial action.

These findings were based on interviews with more than 800 project managers and over 150 hours of observation. The article stresses the importance of standing up to management, which may seem intimidating, but no worse than what'll happen if you don't stand up and the project fails.

This one's well worth reading, folks. Speaking up early is a key lesson that can avoid many problems later. Here's the article...

Want to kill a project? Keep quiet about problems, study finds

PMO Success Story: A.G. Edwards Case Study

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

Some key lessons:

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

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

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

When Failure Is Not an Option - Editorial - CIO

10 Deadly Sins of Software Estimation

Steve McConnell, author, pioneer in the Rapid Development movement, and founder of Construx, a software consulting firm, has done it again.

His latest book, Software Estimation: Demystifying the Black Art, is aptly titled. Poor estimation (whether due to oversight or pressure from management) is one of the leading causes of project failure. McConnell has created a comprehensive, but easy to understand, software estimation "bible."

Of particular note is his "Cone of Uncertainty" diagram, which illustrates in a simple graphic the importance of catching defects proactively, and planning and analyzing risk continuously throughout a project (something I've always touted, and suggest in my own book).

Below is his insightful (and right on the money) presentation on the "10 Deadly Sins of Software Estimation" (in PDF format) ...

Link

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.

Software Projects Doomed From the Start; Blame the Stakeholders

OK, maybe this doesn't top the skateboarding dog (see yesterday's post), but here's an extremely compelling article from the Defense Acquisition University (DAU) on why most software projects are doomed to failure.

Thanks to PMForum for posting this in their news section.

The article states that most software projects come nowhere near their original baselines (although they may come closer to approved revised baselines). It says that stakeholders and the organizational environment, more so than lack of project management skills, bear much of the blame. Here's a quote:

"No amount of training in the technical skills of program management will overcome the simple truth that, as a PM, you cannot make people do what you need them to do. This is the root cause of many software-intensive program failures. Stakeholders often cannot agree on priorities, refuse to standardize business practices, take off on their own proprietary solutions, or simply refuse to participate in the program."

The article also says that the original plans are usually unrealistic to begin with, and underestimate the organizational challenges. It says we make matters worse by holding project managers accountable without giving them the necessary support to be successful.

"... Most expectations of contemporary programs are unrealistic. The cruel reality is that we train PMs and drop them in an organizational 'shark tank' that opposes many of the principles they have just absorbed in their training. Program managers often find themselves in a superfluous role, accountable, yet powerless. "

The article proposes a system of observing stakeholder behavior and rewarding and discouraging behavior as appropriate. Of course, an organization must recognize the problem and commit to doing something about it.

Senior leadership must be actively involved in fostering the changed behaviors. Otherwise, software projects will continue to be underestimated and mired in conflict, despite the best training, the best EPM tools, and the best processes.

I highly recommend reading the full article, "Irreducible Truths of Software-Intensive Program Management", by David Cottengim.

PMFORUM, Connecting the World of Project Management PMFORUM Breaking News: MOST SOFTWARE PROJECTS ARE DOOMED TO FAILURE ACCORDING TO PENTAGON PAPER

Innovation and Project Management - Part 2 of 3

This is a continuation of Part 1, and shows how Tom Kelley's The Ten Faces of Innovation is living proof that innovation and project management are not mutually-exclusive, and in fact, must coexist for true success.

In part 1, we talked about the book's three Learning Personas; The Anthropologist, The Experimentor, and The Cross-Pollinator. Now we'll talk about The Organizing Personas, again adapted from Kelley's book.

The Organizing Personas

4) The Hurdler – Bends the rules to get around roadblocks. Hurdlers tend to be street smart and can cleverly work around the system, undeterred by adversity. Seemingly stubborn at times, they listen to experts, but don’t let them have the final word.

5) The Collaborator – Brings diverse groups together, even if leading from the middle of the pack. Wins over skeptics and creates solutions that cross boundaries. Breaks through silos by being the glue that holds the diverse group together. Works “with” the client instead of “at” them. Prefers to coach rather than direct, coaching behind the scenes and letting the team run with the ball and have the glory. Doesn’t second-guess people from the sidelines.

6) The Director – Assembles the right people and gives them an environment that will allow their creativity to flourish. Has good strategic vision and sets the right theme. There’s no one style that works best. Some lead with calmness and others are bundles of energy. But they all give center stage to others, love sparking new ideas and projects, aim high, and embrace the unexpected with a variety of techniques, strategies, and resources. This role can be on a specific team and does not necessarily have to have a position of “director” authority in the corporation.

Just as an ideal project team should have the learning personas in order to position their project for success, these organizing personas can help turn chaos into order, and failure into success. As Tom Kelly mentions in his book, not every team must have every persona accounted for (and some people can adapt multiple personas), but like any toolbox, we need to know the available tools and use them when they're needed.

Up next in part 3, TheBuilding Personas...

Project Failure Rates Still High, According to National Survey

Apparently, project failure rates are still soaring. So says a national survey of 2,000 project managers and contributors, according to Projects@Work. The article said that only one-third of respondents claim their projects are frequently completed on-time and on-budget, and less than half said their projects frequently meet their goals.

Here are the main causes, as stated in the article:

Nearly 46 percent of respondents said their project teams aren’t often given clear, attainable goals. Nearly 69 percent of respondents said project teams aren’t usually given enough resources to accomplish their goals. And nearly 55 percent of respondents said the right people aren’t usually selected to lead or serve on project teams.

The survey was conducted in the fall by Quality Progress magazine, Kepner-Tregoe, and Guttman Development Strategies, and was just released this month. For more, read on...

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

Managing Innovation Projects; A Different Breed?

I've been reading an excellent book by Tom Kelley, of IDEO (the award-winning industrial design firm). It's called The Ten Faces of Innovation, and from reading it, I'd say there's more than meets the eye that's applicable to project management in general. I'll be posting on that shortly.

Meanwhile, from Innovation Tools comes a good article that talks about the nuances of managing projects that are specifically for the purposes of innovation (i.e. research and experimental projects, etc.).

For example, according to the article:

• Innovation projects tend to start with loosely defined, sometimes even ambiguous objectives that become clearer as the project proceeds. The processes used are more experimental and exploratory and seldom follow strict linear guidelines.
• Teams need to be more diverse and have a higher level of trust as they explore new territory where failure is a possibility.
• With failure as a built-in possibility, innovation teams are more actively involved with risk management and need to learn to fail fast and fail smart in order to move on to more attractive options.
• Also, innovation projects generally need to be sold to project sponsors and funding committees, a responsibility usually not required from normal project teams.

Although I think many of these apply to a good portion of IT projects in general to a certain degree, they are good points nonetheless. For the full article, read on...

Innovation Weblog - Project management vs. managing innovation projects

Collaborative Thinking; The Project Manager's Challenge

Years ago, I read a wonderful saying by Antoine de Saint-Exupery, the author of The Little Prince. He said, "Life has taught us that love does not consist in gazing at each other but in looking outward in the same direction."

That saying stuck with me for some reason, and I was reminded of it again recently as I began to read an absolutely energizing book called Creating We, by Judith Glaser. The book carries the same basic intent as Saint-Exupery, except on an organizational level.

The basic premise is that in order to break through the typical silo thinking and toxic, fear-driven, autocratic environments that drive so many organizations today, one needs to get the players to focus externally on the customer, instead of internally at---or against---each other. Just take a look at this list from the book on why organizations fail:

• Lack of shared focus, shared purpose, and/or shared vision
• Lack of enterprise-wide communication
• Lack of organizational ambition and a strategic approach to getting there
• Lack of respect for others within the organization
• Failure to tap resources and inner talent, creativity, and responsibility
• Failure to break down the walls ("silos") between divisions
• Lack of team cohesion and failure to develop team agreements, rules of engagement, and decision-making processes.
• Failure to focus outside and see the customer
• Lack of hope and spirit; a punishing environment

Is this your organization?

Glaser, whose executive consulting company, Benchmark Communications Inc., has helped many of their A-list clients transform their culture from I-centric organizations to we-centric organizations, offers many compelling case studies and practical advice in the book. I highly recommend it to anyone trying to break down the silos in their organization.

For project managers, it's especially useful, as projects often require facilitating conflicting stakeholders and departments to some sort of agreement. Compounding the problem is that these people are often at higher levels in the organization. To address this, the book offers ways to facilitate we-thinking that are useful from any level in an organization, although ideally it should be driven from the top. For that matter, why not buy a copy for your senior executives (and no, I don't get commission).

Project Failure Rates Soar; Blame the Estimates

How many times have you heard these statements from management?

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

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

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

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

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

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

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

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

Burden of Proof in Project Estimating

Project Managers: Green Means Go?

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

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

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

Tags: Project Management, Project Manager

Agile vs Big-Bang Project Delivery; Argument Solved

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

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

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

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

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

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

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

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

Innovation: Agile Project Teams ...

Companies are trying to break out of "commodity hell" through new product innovation. Embracing innovation requires acceptance that most projects fail and that project teams must be agile - quick, light, etc. Every "failure" yields something of value: data, information, experience, learning, prototypes ... which must be leveraged and reinvested to continue the hunt for the next great idea. ...

... "Bezos isn't just stubborn. He makes his constant experimentation economical by keeping project teams small and nimble. That way, even when they fail, they haven't spent much time or money. " ...

Innovation: Agile Project Teams: Via Business Week: Building An Idea Factory

Why Are Projects Over Budget?

It's a project management epidemic. For years now, the figures have remained pretty much the same. Seventy-five percent project failure rates, many of which come in over budget.

I believe there are three reasons for this.

1) Project managers not tracking the budget closely enough. My view on this is that this is the least frequent reason. Project managers are under siege to monitor costs closely (and it's an indelible part of the process in some organizations), and still the projects don't come in on budget.

2) Bad estimates. Now we're getting closer. Are we learning from mistakes? Do we have checklists to alert us to necessary resources and standard execution times for tasks? If so, much of this can be remedied fairly easily.

3) Pressure to lowball the budget to get the project approved. Ah-ha! This is the silent killer of projects. I contend that project managers frequently either feel compelled to promise a low budget or are pressured to succumb to a low budget in order to get a project approved, and that this is the reason why most projects end up over budget.

In a worst-case scenario, all three reasons exist (and, indeed, this happens more often than we care to admit), but I contend that the third is the most overlooked cause of project failures.

Lesson: Don't feel pressured to come in with a lower budget than you anticipate the project will really need. Stick to your guns when it comes to presenting the case. If the project gets declined, you're better off.

Business Performance Management: IT Project Challenges ...

Project managers need to pay special attention to requirements definition when involved in business performance management, or BPM, initiatives. Craig Schiff discusses the challenges associated with business performance implementations. ...

Business Performance Management: IT Project Challenges: Via DMReview: Maximize Business Performance: Don't Underestimate the Potential Impact of BPM

... "Underestimating BPM's possible payoff goes hand in hand with inadequate sponsorship and support from senior management that relegates BPM to a small IT project to be dealt with in the back office. This tends to result in failure to involve end users in the early stages of requirements definition and a poor grasp of the business issues. " ...

Lessons from Hackers for Project Manager's

The New Hacker's Dictionary defines management as follows: "Corporate power elites distinguished primarily by their distance from actual productive work and their chronic failure to manage (see also suit)."


Hackers, on the other hand, exhibit five distinct attitudes:

1. The world is full of fascinating problems waiting to be solved.
2. Nobody should ever have to solve a problem twice.
3. Boredom and drudgery are evil.
4. Freedom is good.
5. Attitude is no substitute for competence.

These five attitudes provide excellent guidance for project managers, and indeed for all managers. But how does one apply them in the real world?

Read this article to find out!

Project Management Software Learns from Success and Failure ...

Project Management Software Learns from Success and Failure : Via Ferret: CSIRO's Manufacturing and Infrastructure Technology (CMIT): Minimising risk in engineering projects

... "A TEAM of scientists from CSIRO's Manufacturing and Infrastructure Technology (CMIT) has invented project management software that learns from previous project successes and failures. " ...

CSIRO is Australia's Commonwealth Scientific and Industrial Research Organisation. As one of the world's largest and most diverse scientific global research organisations, CSIRO's work touches every aspect of Australian life: from the molecules that build life to the molecules in space.

IT Outsourcing Failure: Poor Governance and Challenging Culture ...

Poor governance and a resistant culture can sink any project or transformation. James Murray explores the situation with IT at Sainsbury, where its significant IT outsourcing contract with Accenture has failed. ...

IT Outsourcing Failure: Poor Governance and Challenging Culture: Via Computing: Supermarket giant reclaims its IT ...

... "the failure of Sainsbury's outsourcing relationship was more the result of management difficulties than inherent shortcomings of the IT outsourcing model. Sainsbury's made some bad decisions... and there was poor IT governance and internal politics issues where some were resistant to working with an external consultancy, he argued. " ...

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

Why SAP Projects Fail

With the recent report of the Irish government canceling two runaway SAP projects, I decided to do some research on what make SAP projects fail (not that they all fail, but when they do, they fail big, since the product is so complex).

Here's a good report from ITToolbox on why projects fail in general, and some feedback comments on why SAP projects fail in particular. As expected, the focus is on lack of communications and cultural change leadership abilities (which I'd say is true of any large project).

To their report, I would add lack of scope change management abilities as well, which ultimately relates to cultural change management. These products are massive, and unless there's a strong leader that can withstand the demands of the organization wishing to make SAP mimic their old processes, it's a scope-creep situation waiting to happen.


Project Management SAP Failure

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

Project Failure: A Success Strategy

Tom Kelley, GM of IDEO and author of The 10 Faces of Innovation, explores the concept of successful failures and the role they have in guiding us forward. Learning from project failures is not just about what went wrong. ...

Project Failure: A Success Strategy: Via Fast Company: Failure as a Success Strategy ...

... "At IDEO where I work, we try to maintain a sense of joyful failure about quick early prototypes, knowing that learning from those first rough versions will point us in the direction of future successes. " ...

Project Success Equation; The REAL Triple Constraint

We've all heard the issues over the triple constraint, and whether it should include scope, time, and cost, or other factors as well. But the "real" triple constraint often goes unnoticed. And that is the old trio of "people, processes, and technology".

We need to invest in all three in order to have project success. By "people," I'm not only referring to investing in leadership training for project managers, but also to having an organizational structure that's aligned and not set up for conflict.

And, while processes are critical, some things cannot be "processized," such as leadership and stakeholder management. And processes alone, without the technology to make it efficient, can also be a burden.

So next time you're analyzing the success or failure of your project, consider the impact that people, processes, and technology had on that result. There may be some eye-openers.

Project Change Management Culture Key ...

Project Change Management Culture Key: Via RTE Business - Morning business news: IT Projects ...

Ingredients for successful IT projects discussed in new book by Maire Kearns, such as instituting a change management culture ...

... "Ms Kearns says that that IT projects fail mainly because of a result of weak project management and a failure to agree on costs and timeframes. She says a company should always agree a fixed time and fixed price basis for a project, this will share the risk and forces a very strict change management culture. " ...

Failed IT projects cost businesses millions, says survey

The KPMG research, which was carried out among 134 major listed companies in the UK, US, Africa, Australia and Europe, found that 56% of the organisations surveyed had to write off at least one failed IT project in the past 12 months. The average loss incurred by the businesses surveyed was £8 million per failed project, whilst the largest single project failure reported cost £133 million. Owch!
For more info see: Failed IT projects cost businesses millions, says survey | OUT-LAW.COM

PMO Project Management Office: The Rocky Road ...

PMO Project Management Office: The Rocky Road: Via CIO: Beneath the Buzz: Project Management Office ...

It takes awhile to win the hearts and minds of the workforce and to gain the leadership alignment necessary for true success of a PMO, project management office. The path to success is a rocky road, filled with boulders and ditches that mirror the culture of the organization. N. Dean Meyer explores the dark side of the PMO and how scoping its role can avoid the common causes of failure ...

... "Meanwhile, relations between Henry and his peers became strained. The other senior managers in IT resented Henry when hot strategic projects were taken away from them and given to him. They resented his control over their resources. They resented his looking over their shoulder, judging their progress and reporting on them to their boss. " ...

Avoid Project Failure (look for clues)

Using a “Top Ten” list as a framework, this article highlights 10 statements that suggest a project is in trouble. Have you ever heard one of the following:

• “This project is too important to fail.”
• “This is going to be a real stretch and lots of long hours over the next year, but if we work hard enough we might pull it off.”
• “We’ve really been in a crunch till now, but I think this new [tool, method, person] will get
  us caught up.”

For the 7 others and some alternatives and remedies for each, download the full article at StickyMinds.com : Article info : Avoiding Project Failure

Fixing Bad Projects

Dr. Martin Barnes, Executive Director, of The Major Projects Association (MPA, UK), explained why many projects fail.

"There are projects where failure is obvious and cannot be denied. On close examination, the chances are that they will contain at least one of four main causes of failure:

- Lack of clarity about what is to be achieved
- Too much complexity, too many interfaces to manage
- Too much technological innovation in the project
- Poor relationships and using the wrong kind of contracts between those who contribute to the project

Any one of these introduces a good chance of failure. If you have all four writ large, there is
no project manager, however competent, who stands a chance of finishing the
project on time and on budget and so that the finished thing works."

Six practices for fixing bad projects are discussed. This is good advice for ALL projects!
See: Max's Musings - Fixing Bad Projects

Project Estimating; Major Causes of Underestimating

Another gem from Conrad Weisert of Information Disciplines. An oldie but goodie (the article, not Mr. Weisert).

This article is a call to project managers to stand up for realistic estimates. Of course, there are always those times when a project must come in on a certain date or else the project just isn't worth doing or won't have the impact it needs.

But even then, you need to ask yourself how risky it is trying to meet that date, and what are the consequences if you do not succeed. If both the impact and probability of failure are high, then it's imperitive to ground the estimate in reality.

Sometimes additional resources can help. Sometimes it adds more risk. It all depends on the situation. In the end, the triple constraint still holds true. The scope, time, and cost must balance.

Read on for more info...

Burden of Proof in Project Estimating

Project Management Soft Skills; Communications, Conflict Management, Ethics, and More

With all the focus on project management techniques, such as planning, scheduling, cost management, etc., it's easy to forget that communication is 90% of a project manager's job. And that includes conflict management, resolving ethical dilemmas, team building - all the soft skills that can make or break projects.

In fact, most project failures are in some way tied to a lack of communication. I've seen many projects where all the techical stuff was done right, but the project was perceived as a failure due to poor communication. Likewise, I've seen project where one mistake after the other was made, but the project was seen as a shining success because it was well communicated.

The site below offers a wealth of valuable articles on the soft skills of project management, including communication, conflict management, ethics in project management, organizational development, and more. Perusing these articles would be time well spent by any project manager or leader.

Point Lookout Archive by Topic - Chaco Canyon Consulting

Why Projects Fail ...

Via IEEE Spection Feature Article: Why Software Fails ...

Robert N. Charette writes about why software projects fail and how we waste billions of dollars each year on preventable mistakes ...

... "Most failures, in fact, can be traced to a combination of technical, project management, and business decisions. Each dimension interacts with the others in complicated ways that exacerbate project risks and problems and increase the likelihood of failure. " ...

Project Failure Rates; Are the Statistics Tainted?

We've all heard the horror stories about 50-75% project failure rates (depending on the industry). But how many projects that come on over-budget or behind schedule do so because the project manager succumbed to pressure to set an unrealistic target to begin with?

I'd argue that by increasing persuasion skills and learning tactics to negotiate proper targets, we'd see project success rates go up exponentially. Certainly there are issues with scope creep, lack of planning, lack of communication, etc., but many projects fail because the project manager was forced to meet an unrealistic and/or arbitrary deadline.

See my entry on Tuesday, August 30th on "Managing Projects with Unrealistic Deadlines," which points to an excellent article for dealing with this issue.

Business Sponsors Critical to IT Project Success

How many of us have had IT projects fully embraced and sponsored by a senior business executive?

I didn't think so.

Unfortunately, lack of full participatory business sponsorship is one of the leading causes of IT project failure. This article from Computerworld offers some compelling reasons why business sponsors fail to get involved, and offers some tips on how to remedy the situation.

The Elusive Executive Sponsor - Computerworld

ITIL Projects: Avoid Pitfalls ...

ITIL Projects: Avoid Pitfalls: Via Opalis Software: Opalis Software, Inc., the expert provider of enterprise infrastructure software that enables the integration and automation of data center operations, announced its top three reasons for Information Technology Infrastructure Library (ITIL) initiative failures ...

Opalis Software shares their experience with ITIL projects and how to avoid the pitfalls: automate, target the necessary processes, and market the efficiency benefits ...

... "Reason #3: ITIL is the Answer Failure – IT personnel often fail to market their ITIL project as a way to drive both internal efficiency and service levels, and try to use the ITIL label as the main message. ITIL projects are costly, therefore, IT staff need to be able to demonstrate up front how it will fortify core business processes and make them more reliable. This demonstration will avoid lost budgets or abandoned projects part way through an ITIL implementation. " ...

Opalis Software, Inc., is the expert provider of enterprise infrastructure software that enables the integration and automation of data center operations. With Opalis, companies can connect disparate environments and automate routine processes in a way that’s simple, fast, and effective. Currently, more than 550 global companies, including Toyota, Harley Davidson, StateStreet, Nokia, Xerox, BlueCross BlueShield, and Woolworths, rely on Opalis server software and integration packs to quickly and easily manage the critical components of their data centers. IT staff can automate processes without scripting or the need of professional services to stay productive and focus on other critical performance management tasks. Opalis is headquartered in Mississauga, Ontario, Canada, and has strategic industry partnerships with EMC, VMware, HP, IBM, Microsoft, NetIQ, Remedy, Veritas, and Cognos.

Are Canceled Projects Failures?

Upon examining studies of failed projects, nearly a quarter of such "failures" are deemed so because the project was canceled. But does a canceled project really constitute failure? Indeed, isn't cancellation of a project sometimes the right thing to do, and by nature a success?

This excellent article from PM Forum explains this phenomenon and offers some valid points to consider.

PMFORUM, Connecting the World of Project Management - Editorials

Customer Driven Project Management

In a true customer-driven environment, communication is often more important than the traditional on-schedule / on-budget statistics. Indeed, it's quite possible for a project that comes in on-time and on-budget to be perceived as a failure if communication was poor. Likewise, I've seen projects that were late and/or over budget be perceived as completely successful because the customer felt involved. There were no suprises. Same thing with the quality of the product being delivered, which is also often overlooked in metrics.

The bottom line is that, if customer expectations were met and they felt involved throughout the project, they'll be happy.

So, in addition to tracking the traditional completion metrics, be sure to measure the quality of the service and the quality of the deliverables vs. expectations. Your customers will thank you and you'll find out how you measure up in those areas.

Cooper StageGate: Portfolio Value Prioritization Techniques ...

Cooper StageGate: Portfolio Value Prioritization Techniques: Via Visions, PDMA's product development e-magazine

Product portfolio management technique applicability to project portfolio management ? ...

... "rank order against financial criterion by calculating expected commercial value. This method goes beyond traditional NPV calculations by recognizing the probability of success in different phases of development such as technical and commercial success or failure. " ...