Project glitches—and sometimes even outright failures—are unfortunately common. But they are by no means inevitable.
According to CIO Insight, “45 percent of large IT projects go over budget, while delivering 56 percent less value than promised.” Yet many of the frequent causes of project setbacks are well understand and can be avoided with proper planning and execution.
Based on research compiled by Dennis McCafferty, here are 10 common sources of project management problems, along with guidance on how to avoid each, illustrated with the example of implementing an enterprise request management (ERM) strategy.
(ERM combines a single intuitive portal with back-end process automation to provide employees with an easy-to-use interface for requesting any type of enterprise shared service, product or resource needed to do their jobs. You can learn more about ERM here.)
The proposal doesn’t contain value points.
Projects can get shot down in the proposal stage if they don’t specify what processes they will improve or their impact on profitability or costs.
ERM replaces disparate department-specific service request processes and systems with a unified portal. It provides measurable cost savings by reducing errors, speeding up both service request and fulfillment processes, and automating approval and scheduling tasks. It also helps with employee retention, avoiding the high costs of replacing talented workers.
Key influencer support is lacking.
Get upper-management support and document it. For an ERM implementation, this should be part of the technology acquisition phase. The compelling business benefits of ERM are powerful arguments in obtaining executive support.
Scope creep veers out of control.
The traditional approach to avoiding this problem is to get sign-off on project scope before it begins; that way, the project can’t be delayed or derailed later by changes in requirements.
The problem with taking that path is that requirements are constantly changing. A better approach than trying to place an immovable stake in the ground is to utilize an agile approach to development, where functionality can be built out incrementally over time, with the flexibility to adapt to evolving needs and priorities.
An ERM implementation can start, for example, with a few common IT processes, then be expanded over time in phases to include other IT services as well as “service items,” resources and products from HR, facilities, finance, and other functional groups.
Users aren’t proactively involved.
Translating business needs into software specifications is always challenging. One way to address this is to give business process owners graphical task-building tools for mapping and automating their own business process workflows, with only minimal technical assistance.
Instead of forcing business users to define exactly what they need, let them build it themselves—in a manner and using tools approved by IT.
Too many team members.
McCafferty writes that “Project teams of eight or less are ideal, because that’s as many as a single project manager should supervise.”
There is a right size for every team, and whether that means eight or fewer members, as written here previously, teams should ideally be made “as large as necessary, as small as feasible, and as passionate as possible.”
The team lineup is wrong.
Tools like competency evaluation can help, but team-building isn’t solely about skills. Even when all team members are talented and their skills are complementary, projects can fail if team members don’t work well together.
Instead, evaluate prospective team members on their ability to collaborate as well as their technical abilities. Highly talented “lone wolves” can play an important role in project success, but they should be called upon and utilized appropriately—not as members of the core team.
Team members aren’t adequately trained.
McCafferty suggests that ” team members need training to understand the big picture objectives, scope, assigned roles, timetables, etc., as well as how to detect and mitigate early trouble signs.”
It helps to have at least one member well-versed in team dynamics, who can keep the group on-task and moving forward. But it also simplifies the process if the “big picture objectives” can be broken down into smaller, more easily manageable short-term goals, using an agile development approach as noted above.
Team members get overwhelmed by the project’s size.
“When a project gets too (un)wieldy, the CIO and lead project manager must break it into doable parts, in stages. Remember: Divide and conquer,” writes McCafferty. Again, an agile approach (see #3 and #7 above) helps mitigate this risk.
The project is defined as a side responsibility of members.
As with any job responsibility, measurement and accountability are vital. People will focus on the tasks upon which they are evaluated.
Whether it’s an ERM implementation or any other type of project, three elements are vital to completion:
- Executive commitment (see #2 above);
- Team commitment (see #5 above); and
- Use of external consulting resources where and as needed.
Processes, tools, and templates are inconsistent.
In business projects, just as when building a house, it’s imperative to have the right tools for the job—and it’s imperative that (the right) team members know how to use them. Common tools should be specified up-front—though of course each member may use tools specific to his or her function or skills as the project progresses.
An ERM implementation requires use of a single portal design tool as well as a single orchestration engine used to automate tasks, collect metrics (such as task completion time) on an ongoing basis, and connect disparate departmental enterprise data sources and departmental management systems.
The ERM approach is designed, however, to leverage in-place technology investments. So, for example, the HR team can continue to use the HRMS it is familiar with—services are simply presented to employees through the centralized ERM portal rather than user-facing HR system screens.
The processes and practices outlined above may not make every project run seamlessly, but they do address many of the most common causes of difficulty. And the ERM implementation process is designed inherently to avoid these common project management pitfalls.
Next steps
Download the white paper Enterprise Request Management: How to Get Started.
Join the Enterprise Request Management group on LinkedIn.
Contact Kinetic Data to discuss your business process optimization challenges.
Cassy Lueneburg