We’re behind schedule again! The network engineer still hasn’t gotten the new IP scheme laid out. How come we need an extra $500,000 for additional access points?
Does this sound familiar? You’re not alone.
According to McKinsey and Company, on average, large IT projects run 45% over budget and 7% over time, while delivering 56% less value than predicted.
IT departments are so resource-constrained; few enterprises can successfully internally staff and complete their digital transformation projects. Budgets and timelines are tight, and projects are expected to be run by the same small teams that are already stretched thin from running day-to-day operations.
Many companies turn to their network and hardware supplier as their “strategic partner” to accomplish these projects. In
Gartner’s 2019 Strategic Roadmap for Networking, they stated that this leads to “suboptimal sourcing, overly complex designs and more expensive solutions.” This isn’t to say you don’t need strong, strategic relationships with your key vendors, but these projects need input and oversight from staff with intimate knowledge of the enterprise environment.
Here are four areas where we’ve seen enterprises routinely underestimate the level of internal effort and skill required to effectively execute a major technology project. These questions should be carefully analyzed before starting any major upgrade project:
1. Do we have enough details of the technical environment to execute successfully?
We are surprised when clients have inadequate information for major IT projects. Often, the planning phase, and the effort associated with it, is overlooked because it’s assumed the needed info is already available. For example, any consideration of a WAN migration/SD-WAN solution would require all current WAN circuits to be identified, including sites, bandwidth, cost, current utilization, expectations for future utilization, identification of traffic flows, and traffic prioritization requirements. Organizations may have the necessary information, but it may be in various disparate locations and in difficult to understand forms. Assembling the needed information at the outset of the project clarifies everyone’s understanding of the environment, sets a consistent version of “the truth” with all parties, and allows a foundation for developing an appropriate upgrade/migration/replacement plan going forward.
2. Does the project timeline realistically allocate the time and effort needed by the project team to do their work?
It makes sense to lean on service providers to do the heavy lifting in network transformation projects, especially when the project involves rolling out a solution across multiple sites.However, in using this model, we frequently find enterprise customers underestimating the “ramp up” effort that will be needed by their internal technical resources before the vendor can begin their activities. Some commonly under-resourced activities include providing vendor teams various levels of environment access, preparing configuration and testing instructions, running initial pilots, adapting rollout plans (when unexpected issues arise), and mapping communication plans to ensure stakeholders are aware of when their location will be impacted.
Similarly, even with a strong project manager on the vendor team, the enterprise customer shouldn’t abdicate oversight – internal staff (or their consultant) will need to pay attention to overall project stewardship to ensure the best possible outcome for the enterprise.
3. Is the project team staffed appropriately to accomplish the work?
Choosing the best equipped IT staff, opposed to the IT staff with the most availability, for an important project can be a dilemma for many enterprise IT managers – even when a vendor team will be performing most of the work. We’ve seen some of our largest client organizations misapply IT project manager duties by assuming they’ll fill in the gaps for their over-extended IT technical team. Unless you’re fortunate enough to have a PMO that supplies project managers with extensive technical IT backgrounds, PMs will typically not supplement the technical stewardship that IT staffs need to provide. Therefore, project staffing and timing need to be based on realistic expectations.
4. Have we adequately identified and involved supporting teams that will be affected by the project?
Though large IT departments are segmented into functional groups such as network, server, security, etc., projects can often crossover into multiple functional areas. In some cases, most of the project may be focused within one group but has collateral impact on other groups. These groups must be contacted in order to gather the information, change the configuration, or even replace the system that will allow the primary group to do their project.
In some cases, the primary group can start their project without involving other groups – but the other groups might be surprised by the impact on their responsibilities (not a good way to keep peace among colleagues). An example of this would be a network team project to upgrade the core switches in a data center that will affect multiple server connections – the server team should be notified of the project in the early planning stages, not just before the changes will happen. Even though a project will be led by a given IT functional group, its impact on other IT (or business) groups must be identified and communicated as early as possible.
Addressing these four areas at the outset of a project is critical to positioning the project towards success. But, it’s not always easy.
PMI reports that only 27% of projects succeed within budget and on time. Clearly, we all have lot of work to do to get that percentage up.
"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communications technology professionals serving clients in all business sectors and government worldwide.
