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.

Influencing People: The Project Manager's Secret Weapon

I recently attended a presentation on self-awareness and influence by Dr. Charles Dwyer, Academic Director of the Aresty Institute’s Leading and Managing People program in the Wharton School. I was so impressed with the presentation that I bought his book, The Shifting Sources of Power and Influence.

This book was a real eye-opener, and a jewel for anyone in project management. In the book, Dwyer states three major challenges we all face:

• Dissonant Value Systems (i.e. people’s conflicting value systems, made even more visible by the advent of the media, internet, etc.)
• Diffused Power (i.e. power being spread around in a matrix fashion, with more and more decentralization and special interest groups, etc.)
• Limited Resources (We all face a limited set of resources, made even more challenging by our lack of a mindset geared towards accepting tradeoffs, or a good mechanism to guide operational priorities)

Sound like any projects you know?

Dwyer goes on to caution that public statements, such as vision, mission, organizational values, etc. may be useful for articulating the values of the leadership or giving people a sense of structure, but do not in themselves change anyone’s value systems. Many leaders assume they can use these statements to change people’s value systems to match organizational values, but this is a myth.

What is needed instead is the ability to influence others by getting them to change their behavior to match your values. To do this, have a clear picture of what you want the unit to look like; set specific, measurable objectives; and insure that people have a way of achieving those objectives.

According to Dwyer, some tried and true methods include asking people for help, offering or implying something in return, or influencing indirectly (i.e. working through someone else who’s in a better position to influence).

Dwyer points out five guidelines for influencing people (I’ve paraphrased them):

1. Insure they have adequate capability (Do they know what to do, have the competence and self-confidence to carry it out?)
2. Address their perception of “Potential Value Satisfaction” (WIIFM or “what’s in it for me”)
3. Address their perception of the probability of value satisfaction (i.e. Do they trust you? You must build trust through visible examples.)
4. Address their perception of cost (Do this by giving them alternatives or a sense of options, and helping them understand the costs and implications.)
5. Address their perception of risk (Try to assume or distribute some of the risk. Don’t ignore it.)

These are the five things everyone weighs in their mind when someone attempts to influence them. In essence, the five elements (four of which are perceptions) make up an equation for behavior. We can influence people’s behavior by addressing this equation (I’ve paraphrased for simplicity):

Behavior=Capability + (Perceived Value * Trust factor) – (Perceived cost and risk)

These are just some of the gems of wisdom in Dwyer's book. He offers reams of memorable examples, often with a humorous style. With 90% of a project manager's job being communication (including influence), I highly recommend Dwyer’s book for project managers, or anyone in a leadership position for that matter.

IT Project Dashboard

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

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

Via ITBusiness Edge: Link

Earned Value Lies and Truths

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

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

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

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

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

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

Project Gates: Are Kill Points Really Considered?

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

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

Queensland University: Controlling phase

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

IT Governance: Firing on All Cylinders ...

An IT Governance Practice Director offers some good insights on successful IT governance, which requires progressing your maturity across multiple dimensions of management: portfolio, project, resource ... leading to the end game of transforming IT into a powerhouse of value creation. ...

... "Successful IT Governance requires effective portfolio, project, process, financial, resource, risk, and communication management. It requires the IT organization to switch its mentality from that of a cost center - We're just here to keep the lights on - to that of a profit center ... " ...

Via ITworld: Getting Started With IT Governance

Einstein Project Management Tip #4: Think Value

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

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

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

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

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

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

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

More Einstein tips coming soon...

Talent and Project Management

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

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

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

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

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

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

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

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

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

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

Project Management Lessons from Mars

Brian Muirhead, the project manager for the Mars Pathfinder program, had some good tips to share with Projects@Work this week.

Some key learnings, extrapolated from the interview:

• Innovation and bold ideas are often necessary to meet what often seems like an impossible challenge. The trick is to balance the cost and time savings with the risks.
• A diverse team is key. It's better to have people that are different, with complementary skills, than have a bunch of people who think and act the same way.
• A small core team that can share issues, problems, and resolutions, with one person at the helm, is an effective way to run a project.
• Trust, honesty, and personal committment are traits that need to be prevalent throughout the team.
• Test, test, and then test again. Don't rely on luck. If you can't test using the exact situation, then simulate it as best you can, testing as much as is possible.
• A team is only as good as it's weakest link. It's up to the project leader to identify those people that aren't up to the task and remove them or find an area that suits them better.
• Ensure team members have opportunities to make personal connections and grow.
• A project manager must simultaneously provide the glue (keeping the team cohesive and focused) and the grease (removing barriers).
  
  Here's the full interview...
  
  http://www.projectsatwork.com/content/Articles/232113.cfm

Project Success Story: Veterans Heath Administration

When Ken Kizer took on the challenge of revamping the horrific state of affars that was the U.S. Veterans Health Administration (many of you have probably seen the movies that showed the sorry state of Veterans Hospitals), nobody suspected that they would go from "last to first."

Forget "Good to Great," these hospitals literally went from "worst to best!"

Reading the writeup on it in this week's issue of Business Week, I was struck by the similarities between Kizer's approach and Napoleon (whom most of you know I'm quite familiar with).

Whereas Napooleon was focused on equality, Kizer was driven by quality and safety. Like Napoleon, Kizer inherited a disastrous state of chaos and provided order, visibility, improvements in technology, training, accountability, decentralized decision-making, and most of all, hope and pride. Also like Napoleon, Kizer had his share of enemies, some who felt he was too arrogant and others who perhaps felt threatened by the changes. Finally, like Napoleon, Kizer was eventually ousted, except by Congress instead of foreign powers.

Fortunately, unlike Napoleon, Kizer's successors continued his methods and his passion. Because of these changes, every nurse and doctor in the network has instant access to electronic patient records, and drugs are filled robotically, avoiding the mistakes common to most other hospitals. And because these hospitals treat the patients for life, they spend more time and money on preventative care, as they realize it costs everyone less in the long run (talk about Total Cost of Ownership!).

I highly recommend picking up this week's Business Week (the July 17th issue with "The Plot to Hijack Your Computer" on the cover). Meanwhile, below is another article that talks about the amazing transformation that Kizer led the VHA through.

Expect to hear more on this as I research this in more depth. I also ordered the book, Straight from the CEO: The World's Top Business Leaders Reveal Ideas That Every Manager Can Use, which is mentioned in the article and apparently covers Kizer's story.

Here's the article (not the Business Week one, but a good one nonetheless) ...

"The Best Care Anywhere" by Phillip Longman

Projects: Cost Management

Lack of project management methods result in poor cost performance. ...

... "Although the scheme's implementation has gone well, the Countryside Agency should have put effective risk and project management procedures in place earlier, he said. " ...

Via BBC: Costs double for roaming scheme ...

ERP Justification: Is it Worth it?

There's a discussion on IT Toolbox about the benefits and disadvantages of ERP solutions that is worth examining.

Some key points this jogged for me (and a few I've added) are:

• ERP improves enterprise visibility, collaboration, and integration. That's the chief selling point of ERP. If that's what your organization needs, ERP sounds like the right solution.
  
• ERP does NOT typically improve individual efficiencies, and should not be sold as such. It's important to set the right expectations up front on just what an ERP system will offer the company and what it will not offer most individuals.
  
• ERP can help achieve cost reduction IF it's replacing many manual steps.
  
• It's not a bad idea to offer SOME predetermined set of key pet reports to decrease resistance. Aside from that, scope should be kept tight.
  
• It's important to have someone running the ERP project with the clout to say no when everyone wants to retain their current way of working (getting past the "I've always done it that way" syndrome).
  
• It's important to ask: Does the company want and need to operate as an enterprise? In most cases, the answer is yes.

However, until the organization reaches "enterprise maturity," chances are it won't realize the full benefits of ERP. On the other hand, an ERP system can help facilitate an organization's maturity in that direction, if that's where they choose to go.

Just some food for thought. I'd be interested in others' experiences and thoughts on the topic.

ERP benefits and disadvantages - ITtoolbox Groups

PPM Software Evaluation Tool; Don't Get Stuck Without It

Yesterday, I posted a link to an excellent article on a software selection process. Now Projects@Work has just announced their PPM Software Evaluation Tool, a downloadable tool that offers "a comprehensive set of questions and parameters for organizations to consider when selecting a project portfolio management solution."

Here's an excerpt from the accompanying article (which is valuable in itself) ...

Don’t settle for presentations and proposals. Regardless of how you proceed through the procurement process, make sure to get your hands on the solution before you make a decision... An ideal, but time-and cost-intensive approach is to pilot the software on one or a subset of live projects before you commit to a full-scale implementation. While this last option will require you to invest in training and a limited installation of the software, if the solution turns out to be the wrong one you have minimized the cost of a failed implementation.

This is sage advice, as many of these tools look great in a demo---or even a brief conference room pilot---but until you experience how easy or difficult it is to actually configure the tools, you don't really know what you're getting yourself into.

As the saying goes, "Fail fast, fail cheap."

Link

SOPM; A New Project Management Methodology

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

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

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

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

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

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

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

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

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

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

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

More to come.

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

Business Process Reengineering Project: Assessment Guide Reference ...

Here are sample screening criteria from GAO guide, when considering whether a business process reengineering project should be undertaken. ...

... "Is the process of strategic importance to the agency's mission? Does the process urgently need dramatic improvement in order to meet the agency's own performance goals?

Is there a high level of customer and/or stakeholder dissatisfaction with the process (quality, timeliness, cost)? Does the process have a long cycle time with many sequential activities, multiple hand offs, checkpoints, and significant waiting time between work steps (e.g., processing a benefits claim)?

Did benchmarking show that other organizations can do the same (or analogous) process much better? Is the process highly dependent on information, so that information technology might be used to speed the work flow, collapse work steps, and improve real-time decision-making? " ...

Business Process Reengineering: Assessment Guide Reference: Via GOA: Framework Part A

Project Management Office PMO: Collaborative Environment ...

An interesting view of the PMO: an environment for IT and business collaboration where contribution is proven. ...

... "The project management office (PMO) was used in a number of cases to provide a collaborative environment for IT staff and business representatives. This environment provided contribution proof, mainly along the lines of time, cost and quality. " ...

Project Management Office PMO: Collaborative Environment: Via ITworld: Keeping score ...

More Earned Value Woes for IT

I mentioned the other day that the IT industry has been struggling to adopt Earned Value Management. There's a three-part series on Projects@Work on Earned Value that illustrates the trials and tribulations thus far. This first part is based on a survey from Primavera that demonstrates just how far behind the IT industry is.

Ironically, this is especially so in the US government (the focus of the Primavera study), despite a mandate from the OMB (Office of Management and Budget) that any IT organization that wants to get their project approved must use Earned Value for tracking cost.

According to the article:

Respondents cite three big EVM challenges:

• 25 percent say they are unfamiliar with EVM;
• 24 percent say they lack personnel trained in EVM; and
• 21 percent say they lack senior management interest.

As the article points out, the latter is the most suprising, considering the OMB mandate. It just goes to show that these things must be driven from the top if they are to be effective.

I suspect part of the problem is that the concepts need to be made simpler for management to embrace it, or at least the focus should be directed at the ultimate EVM figures management would care about, such as "Estimate at Completion," as opposed to the more cryptic Cost Performance Indices (CPI) - although they're valuable as a project manager's tool.

If you really want to turn a senior manager off, just show them an Earned Value metrics chart. Better to sell them on the concepts first and give them the resulting target estimates and planned corrective actions rather than the nuts and bolts of EVM metrics.

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

When IT Projects Impact the Bottom Line ...

Accenture takes financial impact to the bottom-line for over-runs associated with the UK National Health Service IT project, enabling an integrated patient care record. Project issues are related to sub-contractor delivery delays, higher forecast development costs, and lower projected adoption rates. ...

... "The National Health Service's troubled GBP6.2bn IT project has descended into financial misery and corporate recrimination, with Accenture forecasting it will not make a penny from the scheme for years " ...

When IT Projects Impact the Bottom Line: Via Telegraph: Accenture sunk in an NHS mire ...

Accenture Reports Second-Quarter Fiscal 2006 Financial Results: EPS of $0.11 Includes $450 Million Pre-Tax Provision Related to Company’s National Health Service Contracts: "Based on new developments in the second quarter, Accenture now believes that the future costs of deploying systems will exceed future deployment revenues under the current contract terms. As required under GAAP percentage-of-completion rules, Accenture has recorded a $450 million provision for future losses on deployment. The provision is reflected in cost of services for the second quarter of fiscal 2006. The provision, net of lower bonus compensation, resulted in a $342 million pre-tax reduction in operating income and a $0.27 after-tax reduction in EPS in the second quarter. "

PMOs; Where's the Value?

A contributor to eProject's eLounge mentioned this excellent article from Chief Project Officer. It's written by Tom Westcott, founder of Project Solutions Group. Several years ago, I saw him speak on scheduling techniques at the PMI Delaware Valley Chapter's Annual Workshop, and was very impressed with his dynamic style and pragmatic approach.

In the article, Westcott talks about how PMOs must demonstrate value if they are to survive, and offers some good tips on how to do just that. Specifically, he says they must create strategic alignment, deliver real value, and communicate frequently.

Here's an excerpt on what he has to say about delivering value:

PMOs must deliver value to survive. Value is not templates, tools, methodology, processes, training; these are means to driving value. Value is gaining efficiencies, achieving cost savings, increasing customer satisfaction, reducing time-to-market, increasing revenue and profit, reducing deficits, or increasing competitive advantage. Too many PMOs wrap their whole mission and existence around the services they provide instead of their impact on the business. Executives buy value.

Too many PMO directors are former project managers who see their role as project management evangelists. This
leads to a myopic view, and often they are ill-prepared or unable to work strategically with executive management. PMO directors need to speak and think in business terms, financial and organizational. Nix the "project-management speak." How does this project benefit the organization and support our strategy? And how can we get it done as quickly and inexpensively as possible? That's what they care about.

For the full article, read on...

Chief Project Officer: PMO or Bust?

County IT Project Recognized ...

Nice little success story ... County + RCG recognized for innovative solution / IT project. The project shows a good use of IT (content management) with nice tangible financials and quick payback period. ...

... "The project was instrumental in reducing overall process cost associated with County operations. Suffolk County will generate $1.5 million of new incremental annual revenues which will pay for their entire implementation investment in seven months." ...

County IT Project Recognized: Via RCG: RCG IT Project Wins 2005 InfoWorld 100 Award: Award honors 100 Most Creative and Cutting-Edge Implementations of Enterprise Technology ...

Project Managers Need to be Cheerleaders Too

Sometimes the project manager also needs to be the head cheerleader, if you will.

Recently my project team has been suffering with morale issues due to a shifting organizational culture and marketplace. On Friday, the project hit 50% completion. With this, an opportunity was created to remind them that they have accomplished a lot and in fact, all of these accomplishments have collectively resulted in our achieving 50% completion. I praised them and thanked them. This cost nothing but a few minutes of my time. There were no mentions of a hard road ahead - simple, sincere praise and thanks - no ifs, ands or buts.

Cheer your team on - find a reason - any reason. It certainly can't hurt.

IT Projects: Front-End-Load Software Service ...

Software service augments enterprise project management tools to support the front-end-load (FEL) of IT projects: estimates, resource plans, and schedules. ...

... "SCOPE iT Inc., a provider of IT project planning software services, today announced the latest version of its flagship product, SCOPE iT v.5. SCOPE iT is a web-based software service that helps CIOs and CFOs develop more accurate IT project plans, including cost estimates, resource requirements and time schedules. According to the 2004 Standish Group Chaos Report, $55 million annually is wasted on failed IT projects, which represents 22 percent of an average organization’s IT project budget. SCOPE iT is designed to reduce that number and can help double an organization’s project success rate, saving up to 10 percent or more of its IT project budget, while improving compliance with governance initiatives and frameworks such as Sarbanes-Oxley (SOX), ITIL, CMMI, COBIT and Six Sigma.

This latest version of SCOPE iT – v.5 – provides important up-front project planning capabilities – including estimating, forecasting, resourcing, scoping and scheduling – that complement project management and PPM applications. SCOPE iT v.5 includes a number of new features tailored toward large enterprise organizations, including support for project portfolios, user definable cost categories and enhanced management, organization and customization capabilities. " ...

IT Projects: Front-End-Load Software Service: Via ScopeIT: SCOPE IT INC. INTRODUCES NEW IT PROJECT PLANNING SOFTWARE SERVICE: SCOPE iT v.5 Provides Expanded Capabilities To Increase IT Governance Success ...

Keeping Technology In-House Pays Off

A little over a year ago, JPMorganChase canceled its $5 billion outsourcing contract with IBM Global Services and brought its technology operations back in-house.

Says CIO Austin Adams:

"The decision to cancel the outsourcing deal wasn't driven entirely by cost savings... It was about our belief that we wanted to be more involved in every aspect of our business, and technology is a significant part."

And this belief has proven true. The bank is now seeing cost savings from better leveraging of software and hardware deals, and is seeing excellent operational efficiencies as well.

For project managers, this can bring additional benefits, such as having the right know-how in house, and avoiding the need to manage across multiple organizations.

In general, while appearing to be a silver bullet, outsourcing can have negative effects on morale and can damage communities as well. Furthermore it doesn't always bring the cost-savings it promises and puts the organization at the mercy of its vendors. Collectively, there's no telling what the long-term impact will be on the United States.

Companies such as Toyota practice long-term thinking, pride of workmanship, and remain community-focused, with good results. Cheers to JPMorgan Chase.

Here's the full article from Baseline Magazine. There's also an interesting sidebar called "Can You Outsource Project Management?"

JPMorgan Chase Retakes Control of I.T.

Innovation in Project Management; A Lesson from Ford

Tom Peters blogged recently about Ford, Pixar and the new wave of innovation sweeping companies. Although he had a softer spot for what Pixar is doing, the main point was that innovation is the new world order. Operational excellence is out, as is short-term thinking and reactionary cost-cutting. Even GE is now all about innovation.

Just look at these enlightening statements in a recent announcement from Ford CEO, Bill Ford, announcing their renewed focus on innnovation...

Ford Motor Company stands for a far-sighted commitment to growth. We stand for a renewed focus on the customer. We stand for boundless innovation in every aspect of our business...

Here is what we will not stand for: incremental change, avoiding risk, thinking short-term, blocking innovation, tying our people's hands, defending procedures that don't make sense, and selling what we have instead of what the customer wants. In short, we will not stand for business as usual.

Going forward, our employee evaluations will include a section on innovation. We’re also going to design compensation plans that reward new thinking. And we’re going to create a way for employees to appeal a decision, even if they have an idea and the boss says no.

These are inspiring words. Don't be surprised to see this approach make its way into the project management field. Instead of taking a project charter and "executing well," enlightened project managers will encourage opportunity assessments, get their teams and management excited about new ideas and concepts (assuming they're not squashed), and attempt to try new methods.

We've been posting recently about Agile Scrum Project Management. That's just one example of something that's new and different, but will most likely not gain ground in traditional, conservative organizations.

Here's more from Bill Ford's presentation...

Innovation Acceleration: Innovation-Driven Vision: Ford Motor Company

Project Stage-Gates: NASA Improvement Opportunity ...

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

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

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

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