How Do You Pull Together a WAN Project Team?

TeamworkThere is absolutely no doubt that it has been a very long time since there were any fundamental changes to enterprise WAN design. There is also no doubt that there is a broad breadth of WAN-related functionality currently being introduced into the marketplace. This has to leave many network organizations wondering: How do I go about choosing a new WAN design that is best for my company?

I started to answer that question in my last blog in which I discussed a process for identifying WAN-related challenges and evaluating alternative solutions. In this blog I will discuss a process for pulling together a project team and placing a value on their time.

Pulling together a team

As part of evaluating alternative WAN designs, there are a number of components of each design that need to be analyzed. For the sake of example, let’s assume there are four primary components of each design which need to be analyzed:

  • Underlying technologies and the impact of those technologies;
  • The ability to manage the technologies;
  • Security implications associated with the new technologies and design;
  • Financial implications of each design.

One viable option is to have a four person team where each team member is a subject matter expert (SME) on one of the above components. For example, the team could include a SME from the organization’s Network Operations Center (NOC). The role of that team member is to ensure that the NOC will be able to manage whatever technologies are eventually implemented.

Putting a value on your time

It’s important to realize that small companies typically don’t have an issue with pulling together a project team, as their IT organizations are usually comprised of just a few professionals each of whom play a number of roles. As a result, their project teams are often comprised of just one or two people.

That is not the case with large companies, as these companies have a tendency to create large project teams and to analyze alternative technologies and designs very thoroughly. This type of approach might make sense, particularly if that’s what the corporate culture dictates. However, I often advise my clients to think about the opportunity cost associated with that approach.

One of the fundamental differences between an IT consultant and a full time member of an IT organization is how each values their time. For example, my clients usually want me to bid a project on a fixed cost basis. As such, I have to do a careful estimate of how much time I think the project will take and combine that with my hourly rate to come up with a fixed cost for the project. If I estimate too much time, my bid will be on the high side and I run the risk of not getting the job. If I estimate too little time, I will end up not making my usual hourly rate. In either case, once the project is started I am motivated to be as efficient as possible and to avoid having the scope of the project expand far beyond the original specification; a.k.a., scope creep.

I am not saying that full time members of IT organizations are inefficient – very few are. What I am saying is that they seldom apply a dollar value to how they spend their time. For example, consider the four person project team described above and assume that as part of analyzing the choices they have for redesigning their WAN that they identified two alternative approaches:

1) Do a moderately detailed analysis of the solutions provided by their two incumbent vendors and by two other vendors to be chosen by the team.

2) Do a very detailed analysis of the solutions provided by all of the eight vendors that seem viable.

Assume that a very detailed analysis takes twice as much effort as a moderately detailed analysis. That fact combined with the fact that approach #2 involves twice as many vendors as approach #1 means that approach #2 will take roughly four times as much effort as approach #1.

To complete this analysis let’s make two more assumptions:

1) The loaded compensation (salary plus benefits) of each of the four project team members is $130,000 or roughly $2,500 per week.

2) Approach #1 will consume 10 weeks of work from each team member.

Based on a variety of factors, you could make a case for either approach. My advice to my clients is that that when determining which approach to take, the opportunity cost should be considered. In the hypothetical situation described above, approach #1 would cost $100,000 and approach #2 would cost $400,000. Approach #2 would definitely provide more insight, but senior management needs to decide if that insight worth an extra $300,000.

In my next blog I will talk about how to optimize the time spend working with vendors.