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