Many organizations mistakenly think project managers are solely responsible for implementation success or failure. On the surface, such myopic and shortsighted views may appear true — if many tasks are late and over-budget, then of course the overall project will also follow suit.
However, looking more closely it becomes clear that project management is only one dimension among many required for implementation success. For example, a solid business case, executive support, success metrics, and even budget are all critical factors over which the project manager may have little control.
An academic thesis, titled ERP Adoption in Small and Medium Sized Enterprises (PDF download), reinforces the view that project management alone offers a limited, and not particularly useful, definition of implementation success. Although focused on ERP, the lessons hold true for any enterprise software deployment:
[M]uch evaluation of ERP success is based on meeting project targets and milestones but little is done to measure the effect on organizational effectiveness. An unsuccessful project, in terms of project targets and milestones, could still be successful in terms of improved business value.
In this statement, we see the weak link that often prevails between project management and organizational value or benefit. Assuming project participants want to do the right thing, which is usually the case, tunnel vision occurs when team members slavishly aim at narrow project metrics without adequately defining project outcomes that are meaningful to the business.
With this background in mind, I was quite interested to read an InfoWorld article describing asuccessful SAP implementation project. The article presents a flexible and intelligent approach to project management that considers project outcomes in addition to metrics and process. The story describes the project management philosophy used by Daiwa House, an SAP customer:
Lesson No. 1: Having staff wait for work is better than having work wait for staff. All three interviewees were emphatic that moving from traditional project management techniques to critical-chain project management had a huge impact, resulting in 25 percent cycle time reductions for every phase of the effort.
Lesson No. 2: Multitasking is more prevalent and more harmful than anyone thinks.Companies that don’t understand the importance of Lesson No. 1 inevitably attempt to maximize staff utilization. The problem is that most attempts to maximize staff utilization do more harm than good. Employees never multitask, of course. What the word actually means is having to switch from one task to another, unpredictably and often.
Lesson No. 3: Eliminate “apple polishing.” Daiwa House’s project leadership team…provided clear exit criteria for every task. They communicated the importance of avoiding apple polishing often. Then they communicated it more, because if there is anything to be said about the shared culture of engineers, it’s that they constantly strive to find ways to make whatever they’re working on even better.
Lesson No. 4: Don’t overdefine the tasks. “Defining details,” the team explained, “doesn’t help understanding. It causes misunderstanding.” They were emphatic that there comes a point of diminishing returns, below which the project manager is micromanaging instead of allowing team members to use their experience and good judgment to get the job done.
Lesson No. 5: Be aggressive about business improvement. Interestingly enough, as initially chartered, this was very much a classic IT project. Its primary goal was to support management, particularly in accounting, human resources, and compliance by providing a more coherent view of the company’s information. The main expected business benefits were to close the books faster, improve HR management, and support international compliance requirements.
Over time, though, the project team became more aggressive in defining business improvements. Designing different and better processes and practices enabled by the new software became a formal part of the effort. It shifted, that is, from implementing SAP and figuring out how to take advantage of the additional capabilities it provided to implementing better business processes and practices as a central implementation deliverable.
In spite of the name, this project wasn’t an SAP implementation. It was a business improvement initiative that relied, in part, on implementing SAP.
Lesson No. 6: Provide a holistic view for all team members. The folks at Daiwa House were clear on the importance of making sure everyone on the team maintained a sense of the big picture while addressing their individual responsibilities.
These lessons come from an approach, called Critical Chain Project Management (CCPM), developed by the late Dr. Eliyahu M. Goldratt. Goldratt’s Theory of Constraints offers an method for examining the causes, problems, and solutions associated with business change.
Management forgets that projects are just part of a larger system, which is the lynch pin of the Theory of Constraints (TOC). Without this broader view, projects are doomed to failure. To reduce layoffs, for example, one company created an HR policy stating managers must utilize company resources before hiring external contractors; as a result, people with inadequate skills were placed on a project. The project was late, burn rate was high, and everyone was frustrated. Even the best intentions cannot create success without considering both immediate project needs and the organization’s broader business requirements. Traditional project management often overlooks business value in the quest to maintain time and budget metrics.
Advice for CIOs. Traditional project management metrics are only important to the extent they support desired business outcomes. Successful projects achieve deadlines and budget but alsodeliver real business results. Try this test: ask your project managers to articulate specific business outcomes that users expect. If the answers are murky or unclear, then perhaps it’s time to bring your team closer to the users.
Image from iStockphoto
(Cross-posted @ IT Project Failures Blog RSS | ZDNet)