Six lessons for intelligent project management

Six lessons for intelligent project management

Summary: Traditional approaches can isolate project goals from business outcomes. The solution is bringing project managers closer to those working in lines of business.

SHARE:
2

Leaders in many organizations mistakenly think that project managers are solely responsible for implementation success or failure. On the surface, such myopic and shortsighted views may appear true -- if lots of tasks are late and over-budget, then of course the overall project will 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 the team slavishly aims at narrow project metrics without adequately defining outcomes that are meaningful to the business.

Continue reading to see the six lessons »»

With this background in mind, I was quite interested to read an InfoWorld article describing a successful 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.

I asked author and project management expert, Todd Williams, to explain how Critical Chain Project Management avoids common pitfalls on many implementations:

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 also deliver 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

Topics: CXO, Software, IT Employment

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • Not really new... but an important reminder

    Not really groundbreaking... theory of constraints has been around since the 90s, if you add that plus Kanban+ Lean you get all the things in that list.
    Of course we are still doing a poor job managing projects as an industry so these things need to be repeated.
    raul.vejar@...
  • Great lesson points, except #4

    Great points Michael! Thanks for sharing.

    I think Lesson #2 is the one of the best points. At PIEmatrix, we have discouraged multi-tasking after finding our team members we getting frustrated with swapping focus and taking time to get ramped up again.

    I respectfully disagree with lesson #4. I would agree if the task has bad details. However, a well-written task descriptions has great power.

    For example, let's say we had a task "Obtain executive sponsorships." The person responsible marked it complete after receiving an email from the executives saying they were "on board" with the project initiative. Halfway into the project, the initiative was killed in favor of other priorities.

    What if the task had a detailed description providing the secret sauce on how really get the executives to really support the project. This could include agreement on business value, amount of time participating with key decisions, commitment for reviewing progress, communication delivery preferences, and revisiting value and benefits during the initiative. Assuming these are considered proven and good practices, the chances of the success with this task would be higher with it's detailed description. In addition, the person accountable for the task could be a hero.
    Paul Dandurand