You know and love our Must-Read IT Blogs lists, but now, say hello to the nonprofit side.
In small businesses with limited resources, an individual with the ability and aptitude to multi-task, offer strategic insights and serve as a utility infielder with functional expertise makes an attractive hire.
Yet when a project manager exhibits those same crucial skills and the willingness to "pitch in" on the technical details, it could be the kiss of death for an important technology project, such as a major systems upgrade or architecture overhaul.
Management experts agree that the project manager—a key player in keeping a project on track—should not take on technical tasks. That may violate the operating procedure of most small businesses; still, the separation of duties is worth considering on major projects. The reason is simple: When a project is in trouble, the project manager who is accustomed to working on technical tasks will focus more intently on those same tasks in an attempt to keep the project on track and set an example for the rest of the team. In the meantime, broader and more important project management functions get ignored.
One of the primary reasons major systems upgrades or architecture overhauls fail is a relatively inexperienced project manager. In a larger company, there are typically seasoned professionals that the project manager can turn to for guidance. Small businesses also can benefit from a deep management bench that will help keep projects on track.
Dan Vos Construction, an Ada, Mich.-based commercial builder, provides just such a support system for project managers. "We have other, more experienced project managers who can jump in and help out in areas where somebody is weak," says Todd Musser, Dan Vos's IT manager and 3-D designer. The design department has an open floor plan, and the lack of physical barriers encourages employees to share input. In addition, the company maintains a roster of outside resources it can call on for additional help.
Whether the company is a small start-up or an established corporation, effective communication and reporting are the keys to managing a project of scale.
An inexperienced project manager might take advantage of the informal reporting structure of most small firms and provide status updates while passing colleagues in the hallway. This might suffice on a one-person project. However, a rigid reporting structure makes it easier for the project sponsor to understand progress and delays.
Rick Myers, chief technology officer of Optas, uses a combination of custom and off-the-shelf reporting tools to track and communicate potential problems. The 45-person company in Woburn, Mass., provides privacy-safe database marketing software and services for pharmaceutical companies and health systems.
"The key, we've found … is more people keeping track of what they're doing," says Myers. The seven IT staffers in his department track and check off items that must be completed. In addition, Myers and his team meet biweekly, or more frequently if needed, to review the status of projects.
"Proper planning and regularly checking on the status" are vital to keeping a project on track, adds Myers.
Yet knowledge isn't always power. Reporting tools may simply uncover signs that a project has reached a break point—signaling an inevitable downward spiral toward project failure. At that time, a decision must be made to rescue the project or continue operating within the same boundaries and assumptions that led to the project break point.
While counterintuitive for many small businesses, the process of formalizing progress and status reports, keeping project managers out of the technical details and designating pinch hitters from the senior staff can keep big, and potentially wayward, projects on track. But even with these measures in place, the most well-intentioned projects can spin out of control. When that happens, a project intervention may be the only option.
When a project is in trouble, the most unpleasant choice—canceling the project—might be appropriate in some situations. However, a well-planned and well-defined project rescue can reverse the downward spiral by challenging the status quo and enabling project team members to make the difficult decisions necessary to salvage the initiative.
Some general steps to rescuing a project apply to technology projects as well.
First, recognize the problem: This is undeniably difficult. People will plead, "I just need one more month. I'm so close." But, in many situations, that last month never delivers.
Most projects don't suddenly bite the dust. Any of these red flags can be a warning that management needs to hit the pause button and evaluate just where the project stands:
Next, pause the project. This act immediately halts burning more hours and costs against the project. And taking a break gives management a chance to regroup and make a new plan.
Once the pause button is hit, conduct a project audit. An audit will help uncover the root cause of why things are going wrong. The primary reason a project goes off-track is usually that the project manager is relatively inexperienced for the project's size and/or scope. But before making that determination, review the project and determine how long it will take to complete the required tasks. Don't assume that things will get better or that tasks will take less time.
At this point, validate the return on investment. Someone had a reason for the infrastructure upgrade or application rollout in the first place. So figure out if the potential benefits make the project worth continuing. Compare the value of this project against other IT alternatives and initiatives. If it still makes sense, put the project back into the IT governance hopper.
Once the project is back in the hopper, restart the project with new dates and milestones. Beware of roadblocks such as apathy and disbelief that may be thrown in the way of the rescued project. People take cues from their leaders, who must tell people the project is important and reinforce that message with their own behavior.
Most projects are well into the development phase—some are even in the testing phase—before a strong case can be made to formally launch an intervention. However, by spotting the telltale signs early in a project's life cycle, it may be possible to salvage much of the original scope of a troubled project.
Joseph J. Zucchero recently co-authored Project Rescue: Avoiding a Project Management Disaster.