By Suzanne Thornberry
Joe Zink, now a system administrator with CNET Networks, once watched a fellow consultant's project turn into an expensive failure when the two worked together in San Jose. "His project cost went from $1 million to $3 million to cancellation," recalls the IT professional, adding that the project fell victim to scope creep—one of the most common reasons for project failure.
According to Gartner research, IT and application development projects often fail to be completed on time and on budget. In many small and midsize businesses, one third of the projects exceed budgets and schedules by almost 100 percent. In one particular industry, the scenario was even worse: Gartner analyzed tech projects implemented by healthcare delivery organizations and predicted that more than 60 percent would be at least 30 percent late or 20 percent over budget.
Fortunately, savvy IT leaders can help reduce the risk of cost overruns and outright failures by insisting on a thorough planning process that involves not only IT, but also any departments affected by the project.
1. Establish the scope and features before beginning work
Scope creep, according to consultant and author Richard Veryard, is known by various names, depending on the project phase. Early on, it's called "requirements creep," when the project team is defining problems to be tackled. Perhaps most often, it's called "feature creep," as more "solutions," or functions, are added to the specs.
The primary way to fight scope creep seems simple: Firmly establish the requirements and features of the project before getting started. But too often, in-house customers believe that an IT project can always make room for one more feature.
TechRepublic member Jesse Lo RE, VP of DigitalNine Corp., said that IT leaders need to establish a cross-departmental steering committee of project stakeholders as a first step to define the requirements. Lo RE believes that because project overruns are usually a result of factors outside of the project team, the steering committee can provide the "organizational buy-in" that's necessary to keep the project on track.
Jon Nelson, a TechRepublic member and CTO of Avnet Inc., said that once project requirements and features are mapped out, the next step is putting the requirements in writing and having a representative of each user community sign off. "If it's not written, then it's not real" is Nelson's first rule of project management. He pointed out that an e-mail validation is deniable, but a personal script on a paper contract is not. Maybe that's why in Nelson's 15-year IT career, none of his 16 large-scale projects have run over in time or budget.
Then, Nelson said, it's time for each business unit to prioritize its individual requirements.
2. Prepare your technical team to do its best
The early process of project planning encourages stakeholders to take ownership as they sign off on requirements. The next phase involves getting technical staff to sign off on capabilities and responsibilities.
At this stage, Nelson said it's critical to have a thorough understanding of the systems and tools that will be used to design and develop the project. The technical staff needs to validate the capabilities and weaknesses of the development environment.
"This step is so crucial," Nelson explained, "because it is at this step where the designers and developers testify to and commit to their own capabilities to deliver."
You should also take into account not only the staff's capabilities, but personalities, desires, and styles during this phase. With those factors in hand, you can then assign teams, determine schedules, and even provide working environments that provide the best potential for success. For example, if some people work best between noon and midnight, try to provide the flexibility to work those hours for optimal productivity. "After all," Nelson said, "the speed, quality, and value of your project is not a factor of the technology nearly as much as it's a factor of the technologists."
3. Thoroughly investigate a vendor's capabilities
While Nelson's advice can help tech leaders properly prepare the project team , few IT efforts are accomplished without help from an outside vendor. If the vendors are providing hardware or software components, it's a good idea to proceed cautiously.
Troy Atwood, an associate VP at CNET Networks, cites overpromising vendors as one chief cause of cost overruns, along with scope creep.
Atwood recalled a project deploying relatively new VPN WAN technology for TechRepublic as an example of a vendor overselling a product. Atwood and his colleagues interviewed three different companies, eliminated one early in the process, and then grilled the remaining two "very hard" on their technologies.
"I have a standing requirement for salesmen: I will not see them unless they bring a technical specialist with them," Atwood explained.
A major networking vendor won the contract, but Atwood and a colleague spent many nights on the phone with the company's tech support to iron out various issues. In retrospect, Atwood said the tech specialists they had met and talked with initially were actually trained on future product enhancements—not current technology in place. As the technology itself was so new, the team was not able to find help among colleagues and peers, either.
But Atwood later learned that there were people in the same boat. When TechRepublic was acquired by CNET, he discovered that CNET had experienced the same problems with the vendor. The experience taught Atwood a big lesson that most tech leaders learn: Even if you cover most of the bases, you are still running huge risks being an early adopter.
Fortunately for Atwood, two factors kept potential project overrun low. First, his team was highly trained and eventually ironed out the issues, saving the cost of hiring outside consultants. And second, the IT department had bought hardware that exceeded current needs. When the networking vendor finally released an improved IOS upgrade that fixed many of the issues, the hardware was already in place to handle the more demanding system. This forward-looking approach is rooted in one of Atwood's favorite mantras on project management: "Failure to plan is a plan to fail."
An ideal way to head off vendors who exaggerate products' capabilities is to find other techies who have implemented them. But that's not always easy, particularly for early adopters. "Communication helps you try to bridge the gap, but you never really bridge it," Zink said. "There's little in IT that we have been doing for five years."
4. Stay diligent about keeping the project on the right path
Even if initial planning includes business unit involvement, project teams still have to guard against scope creep after the project is underway. Zink believes that scope creep will always be a problem, due to the very nature of IT.
"IT is simply different from just about any other project, as the project is going to change in scope," said Zink, adding, "or, at least, someone is going to try to change the scope." Some IT leaders may allow minor changes if specified in writing, and the cost and time impact is approved. But others, like Nelson, have written contracts that can be used to close the project to any changes once underway.
Nelson also emphasized the human touch in keeping a project on the right path. He tries to maintain a strong dedication to the spirit, pride, and concerns of the development and deployment teams. Nelson lets his teams know that he's there throughout the process. Even in a 24/7 development environment, Nelson wrote, "if a member of my team was working, then I was working."
As a project moves along, it's important to keep user communities, as well as executive management, informed on progress. Recognizing milestones can help keep the team focused and give them something to celebrate. Milestones also can help you publicize your team's successes throughout the organization.
Zink, who holds a degree in accounting, recognizes another value of tracking a project: discovering what's not working.
"Try to discern early what areas or paths are leading to dead ends," Zink advised. If you can't find a path around those dead ends, it may be time to abandon the project before you sink three times the budgeted money into it, as his colleague in San Jose did.
And, Zink added, don't be surprised if something slips somewhere, despite best efforts. It'll simply be in sync with his favorite law of project management: It always takes longer than you expect.
According to Gartner research, IT and application development projects often fail to be completed on time and on budget. In many small and midsize businesses, one third of the projects exceed budgets and schedules by almost 100 percent. In one particular industry, the scenario was even worse: Gartner analyzed tech projects implemented by healthcare delivery organizations and predicted that more than 60 percent would be at least 30 percent late or 20 percent over budget.
Fortunately, savvy IT leaders can help reduce the risk of cost overruns and outright failures by insisting on a thorough planning process that involves not only IT, but also any departments affected by the project.
1. Establish the scope and features before beginning work
Scope creep, according to consultant and author Richard Veryard, is known by various names, depending on the project phase. Early on, it's called "requirements creep," when the project team is defining problems to be tackled. Perhaps most often, it's called "feature creep," as more "solutions," or functions, are added to the specs.
The primary way to fight scope creep seems simple: Firmly establish the requirements and features of the project before getting started. But too often, in-house customers believe that an IT project can always make room for one more feature.
TechRepublic member Jesse Lo RE, VP of DigitalNine Corp., said that IT leaders need to establish a cross-departmental steering committee of project stakeholders as a first step to define the requirements. Lo RE believes that because project overruns are usually a result of factors outside of the project team, the steering committee can provide the "organizational buy-in" that's necessary to keep the project on track.
Jon Nelson, a TechRepublic member and CTO of Avnet Inc., said that once project requirements and features are mapped out, the next step is putting the requirements in writing and having a representative of each user community sign off. "If it's not written, then it's not real" is Nelson's first rule of project management. He pointed out that an e-mail validation is deniable, but a personal script on a paper contract is not. Maybe that's why in Nelson's 15-year IT career, none of his 16 large-scale projects have run over in time or budget.
Then, Nelson said, it's time for each business unit to prioritize its individual requirements.
2. Prepare your technical team to do its best
The early process of project planning encourages stakeholders to take ownership as they sign off on requirements. The next phase involves getting technical staff to sign off on capabilities and responsibilities.
At this stage, Nelson said it's critical to have a thorough understanding of the systems and tools that will be used to design and develop the project. The technical staff needs to validate the capabilities and weaknesses of the development environment.
"This step is so crucial," Nelson explained, "because it is at this step where the designers and developers testify to and commit to their own capabilities to deliver."
You should also take into account not only the staff's capabilities, but personalities, desires, and styles during this phase. With those factors in hand, you can then assign teams, determine schedules, and even provide working environments that provide the best potential for success. For example, if some people work best between noon and midnight, try to provide the flexibility to work those hours for optimal productivity. "After all," Nelson said, "the speed, quality, and value of your project is not a factor of the technology nearly as much as it's a factor of the technologists."
3. Thoroughly investigate a vendor's capabilities
While Nelson's advice can help tech leaders properly prepare the project team , few IT efforts are accomplished without help from an outside vendor. If the vendors are providing hardware or software components, it's a good idea to proceed cautiously.
Troy Atwood, an associate VP at CNET Networks, cites overpromising vendors as one chief cause of cost overruns, along with scope creep.
Atwood recalled a project deploying relatively new VPN WAN technology for TechRepublic as an example of a vendor overselling a product. Atwood and his colleagues interviewed three different companies, eliminated one early in the process, and then grilled the remaining two "very hard" on their technologies.
"I have a standing requirement for salesmen: I will not see them unless they bring a technical specialist with them," Atwood explained.
A major networking vendor won the contract, but Atwood and a colleague spent many nights on the phone with the company's tech support to iron out various issues. In retrospect, Atwood said the tech specialists they had met and talked with initially were actually trained on future product enhancements—not current technology in place. As the technology itself was so new, the team was not able to find help among colleagues and peers, either.
But Atwood later learned that there were people in the same boat. When TechRepublic was acquired by CNET, he discovered that CNET had experienced the same problems with the vendor. The experience taught Atwood a big lesson that most tech leaders learn: Even if you cover most of the bases, you are still running huge risks being an early adopter.
Fortunately for Atwood, two factors kept potential project overrun low. First, his team was highly trained and eventually ironed out the issues, saving the cost of hiring outside consultants. And second, the IT department had bought hardware that exceeded current needs. When the networking vendor finally released an improved IOS upgrade that fixed many of the issues, the hardware was already in place to handle the more demanding system. This forward-looking approach is rooted in one of Atwood's favorite mantras on project management: "Failure to plan is a plan to fail."
An ideal way to head off vendors who exaggerate products' capabilities is to find other techies who have implemented them. But that's not always easy, particularly for early adopters. "Communication helps you try to bridge the gap, but you never really bridge it," Zink said. "There's little in IT that we have been doing for five years."
4. Stay diligent about keeping the project on the right path
Even if initial planning includes business unit involvement, project teams still have to guard against scope creep after the project is underway. Zink believes that scope creep will always be a problem, due to the very nature of IT.
"IT is simply different from just about any other project, as the project is going to change in scope," said Zink, adding, "or, at least, someone is going to try to change the scope." Some IT leaders may allow minor changes if specified in writing, and the cost and time impact is approved. But others, like Nelson, have written contracts that can be used to close the project to any changes once underway.
Nelson also emphasized the human touch in keeping a project on the right path. He tries to maintain a strong dedication to the spirit, pride, and concerns of the development and deployment teams. Nelson lets his teams know that he's there throughout the process. Even in a 24/7 development environment, Nelson wrote, "if a member of my team was working, then I was working."
As a project moves along, it's important to keep user communities, as well as executive management, informed on progress. Recognizing milestones can help keep the team focused and give them something to celebrate. Milestones also can help you publicize your team's successes throughout the organization.
Zink, who holds a degree in accounting, recognizes another value of tracking a project: discovering what's not working.
"Try to discern early what areas or paths are leading to dead ends," Zink advised. If you can't find a path around those dead ends, it may be time to abandon the project before you sink three times the budgeted money into it, as his colleague in San Jose did.
And, Zink added, don't be surprised if something slips somewhere, despite best efforts. It'll simply be in sync with his favorite law of project management: It always takes longer than you expect.
Posts
