What's the recipe for project management success? Many IT professionals agree that buy-in and support from top management, clearly defined scope and requirements, good communication, and the right project resources top the list of key ingredients.
Those aren't the only factors influencing the successful outcome of a project, of course. IT professionals also rank a project management methodology (or process or framework), the need to manage expectations, and a highly skilled project manager as crucial.
Recently, 83 members of the CIO Forum on LinkedIn essentially developed a comprehensive guide to project success factors while participating in a discussion on ways to ensure the successful delivery of an IT project.
Some of the top success factors mentioned were obvious--others, less so. Here, CIO.com shares some of the less obvious, but no less important, factors influencing project success. (And by less obvious, we mean factors that don't immediately come to mind, get easily overlooked or that get short shrift when the going gets tough on a project.) We compiled this list, which is by no means exhaustive, based on comments raised in the CIO Forum discussion and during phone interviews with project management experts. Feel free to leave your two cents in the comments section below.
1. A Clear Definition of Success
You can't achieve success if you don't know what it looks like, maintain several members of the CIO Forum. Steve Hawthorne, global project manager at Integra LifeSciences, says project success must be defined in terms that are meaningful to the business.
"Too often as IT professionals, we assume that success is defined as on time, on budget, and meeting the defined requirements," wrote Hawthorne in the CIO Forum. "While these are important, it is [equally] important to understand the expected value proposition of the project and to drive project efforts to ensure that it is achieved."
In other words, even if the project is completed on time, on budget, and meets all requirements, it may still be considered a failure if it doesn't deliver the expected business value.
2. A Willingness to Make Unpopular Decisions
Bronnie Brooks, an IT consultant and project manager who participated in the CIO Forum discussion, told CIO.com that she's had to make tough decisions over the years that were unpopular with either her client, her manager or her team in order to keep projects on time, within budget and with the right resources intact. For example, she says she once had to tell a client that a feature they were expecting in an upcoming software release wouldn't make it and that they would have to wait for the following release, a year later. Another time, she had to move a team member a client liked onto another project on which that team member's skills were needed.
Making tough decisions about project resources and priorities can be difficult for some IT project managers who want to please everyone and who want to believe, like everyone else, that the project will work out, Brooks says. But making tough calls is crucial, she adds.
"Sometimes the best decision will not be the most popular one," Brooks says, "but it will get you further down the road."
3. End-User Training and Hand-Holding After Go-Live
You'd think training end-users on whatever new system is being deployed would qualify as an obvious success factor, and to many IT professionals, it probably is. But too often, systems implementations fail--not because they're delivered late or because they're over-budget--but because end-users haven't been adequately trained. Consequently, they don't adopt the new system.
"You can never put enough emphasis on training or pay sufficient attention to hand-holding post go-live," wrote an IT manager from Spain in the CIO Forum. "I would say that most IT project failures come out of inadequate user-side training and poor management of the most critical phase: post go-live."
4. Clearly Defined Roles and Responsibilities
Sometimes, the people involved in a project--the project manager, team members, steering committee members and sponsor(s)--don't understand their roles and responsibilities because no one defines them, says Chet Ung, an IT auditor with The Wood Group who participated in the CIO Forum discussion and spoke with CIO.com over the phone.
If, for example, project steering committee members don't understand their role, they don't know what they're supposed to contribute, says Ung. They don't realize they have the ability to change the course of a project. Consequently, they don't contribute anything in meetings because they don't know what questions to ask--let alone that they can ask questions. Projects can fail when the steering committee doesn't play the oversight role it's supposed to, he says.
"Roles and responsibilities need to be outlined and documented to set expectations and avoid confusion on what level of contribution each project member makes," Ung wrote in the CIO Forum.
5. Transparent Workflows
When project workflows are transparent, every person involved in a project knows exactly what his or her role is as well as what's "upstream and downstream" of that work, says Stacy Goff, president of the Colorado Springs-based project management consulting and training firm ProjectExperts. In other words, they know what work has been done on the project before them and by whom, as well as what work will be done after them.
Transparent workflows can save time and improve project quality, adds Goff. "If you know you have something from someone who does excellent work, you won't have to fill in any blanks. You're comfortable accepting what you read," he says. Similarly, if the person to whom you'll be sending your work is very diligent and detail-oriented, you may spend more time perfecting your product so that it meets the next person's high expectations.
6. A Process for Managing Scope Changes
End-users of a system being developed or a new process being implemented often want to make changes to the system or process as they see it unfolding. Little do they realize that even minor changes can dramatically affect the project's cost and timeline.
Sometimes the project manager or implementation team being asked to accommodate these additional scope changes doesn't realize how, say, the addition of three buttons on a user interface, can impact the project's budget and schedule, especially in the case of external consultants, says Chris Spivey, founder of project management and rescue consultancy Spivey & Co. Wanting to please end-users, adds Spivey, the consultant or project manager agrees to add the three buttons, saying it should be an easy change, only to find out from the technical design teams that adding those buttons pushes the project by three months because of the additional work it creates.
"Someone has to go back to the users and say, 'We really didn't know what we were talking about. We thought this was a simple change, but it's going to add three months to the project,'" says Spivey.
Having a change control process sets everyone's expectations that requests for new features or functions need to be formally requested and will go through a formal vetting process to determine how much work they will require and how they'll affect the project's cost and timeline. With a formal change control process, a project manager can more definitively say whether or not a particular change truly is minor, says Spivey. Moreover, the project sponsor can make a more informed decision about the additional features and functions that are truly worth extending the cost and schedule of the project.
With a formal change control process, there are fewer surprises, which makes everyone happy.
7. Risk Management
"Risk management is a key part of project management for any size project," says ProjectExperts' Goff. "It should be part of any level of planning, whether initial project planning or phase- or stage planning for each new portion of a project. All too often I see it done upfront and then not revisited."
Risk management is so critical, adds Goff, because it provides project managers with a forward-looking view of both the threats that could throw the project off track and the opportunities to improve it. Risk management practices also provide project teams with an opportunity to engage the people, such as project sponsors and end users, who could control the risks that might threaten a project, he says.
8. Adequate Documentation
Without proper documentation, project teams may not capture the right functional and technical requirements for a project, says IT Auditor Ung. And without proper documentation of various requirements, the project team could spend a lot of time, effort and money on a project that doesn't meet the sponsor's or end-users' expectations.
Project teams also risk moving forward with a project that lacks an execution plan or a project charter, both of which are documentation critical to the success of projects.
Lack of documentation, says Ung, "creates a lot of confusion and uncertainty about the direction the project should be going in." Confusion, in turn, creates conflict, delays and cost overruns.
9. A Good QA Process
Quality assurance efforts such as integration testing, black box testing, functional testing and stress testing often get short shrift on projects, says Ung. Sometimes it's because the project manager isn't familiar with the different types of QA testing, he says. Other times, the project manager has to cut corners to meet a looming project deadline. Because QA often gets left to the end of a project, it's a frequent victim of cost-cutting. Regardless of the cause, the result is software, a system or a new process that doesn't work properly.
"A good QA process is very important," Ung wrote in the CIO Forum. "A QA team would ensure that requirements and functionality are intact before end users get a hold of the product. It only takes one negative view to domino the perception that the project is a failure."
Peter Scheyen, CTO at the Richard Ivey School of Business in London, Ontario, Canada, recommends doing early demos to solicit feedback from users. Getting early feedback is one of the most effective ways to reduce the risk that a project doesn't meet end-users' needs (and thus becomes considered a failure), he wrote in the CIO Forum.
10. Project Governance
Governance sets the framework for how a project or program will be managed, according to Ung. "It also establishes a common understanding or language for the project team to follow," he adds. "When you have good project governance, the people who are involved with the project understand what they need to do."
When project governance is lacking, staffers may execute a project inconsistently. For example, the development team might use one project management framework, while business analysts might use a different process. Inconsistent project execution raises the risk of failure.