Enterprise Software

Member loves linear project process but sees positives in parallel plan

Sometimes a project doesn't take a simple, linear form. How do you decide when a single project should be split into two or more parallel projects? Here's how one TechRepublic member, a network architect, handled the dilemma.


Many IT projects can’t be completed by the book or follow a linear process that some project managers prefer. TechRepublic member Martijn Dekkers is a proponent of the linear process for project management.

But Dekkers, chief architect for Malta Information Technology and Training Services Ltd., had to wrestle with his linear bias when he began work on a project that has forced him to stray from the step-by-step approach. His experience should help other IT managers who face similar challenges.

Dekkers modified his favored linear approach and adopted a parallel approach based on demands from his client and the complexity of his current project involving 8,000 PCs and several data centers. His parallel approach, in this case, lets him build the solid foundation he strongly believes is necessary in parallel with other needed improvements. He expressed his views on building a solid foundation in a recent discussion thread linked to “Knowing when speed matters,” a TechRepublic article by Bob Artner.

Artner proposed in his Artner’s Law column that the need for speed of development of a project often outweighs the need to deliver a complete result because senior managers and clients require rapid responses.

Dekkers wrote that the choice between speed and perfection shouldn’t exist. The project should be built in phases, beginning with a solid foundation and improved with time. Dekkers equated this to building a bridge, saying it is unfair to the client to hastily build a bridge and then rebuild an improperly built bridge.

Artner answered Dekkers by saying that sometimes it’s best to build a temporary bridge while the better replacement is being built. Dekkers agreed that in some situations, including the new project he is working on now, building a project with parallel processes can work.

We contacted the Dutch-born Dekkers at his Maltese headquarters in that island republic southeast of Italy. We wanted to know more about how he decides when to relax his belief in a linear engineering concept and incorporate parallel processes. When do you build two bridges instead of one to save time?

A real-world example
The project Dekkers is working on now has “nightmare” written all over it.

He is planning and building a team to implement enterprise management architecture for a client with more than 8,000 PCs and several small- to medium-sized data centers. There are 600 IP subnets serving 200 sites, more than 350 NT domains, and no one knows how many user names and network permissions. There are a variety of operating systems in place with some machines still running legacy applications and Windows 3.11.

Support costs for the network are astronomical because all of it has to be done manually for each machine, Dekkers said. Asset management is outdated.

“The situation, from a technical as well as a business process point of view, is untenable,” he said.

The client didn’t ask Dekkers what should be done but told him they wanted to use specific enterprise management software.

“I assessed the environment and concluded that before any type of enterprise management will make sense, the environment will require a drastic simplification,” he said.

While simplifying the network, Dekkers proposed to his client that business processes could be coordinated with the IT systems as a parallel project.

After these two improvements, the enterprise management system could be planned and implemented.

Reaching agreement with the client
Dekkers said that the client has agreed to this parallel approach (simplifying the network and improving the business processes) on the premise that:
  1. A less-complex environment will require a less-complex (therefore cheaper) enterprise management implementation.
  2. The cost of deploying enterprise management on the current environment would roughly be the same as the proposed overhaul—plus the first phase of the enterprise management implementation.
  3. The overhaul of the current environment will lead to other cost-savings, besides those facilitated by the enterprise management implementation.

“In most cases, building on a solid foundation makes sense. In this case, ROI would be gained at approximately the same time as without building the foundation,” Dekkers said. “In this case, I showed a clear ROI at a specified time. I also showed that just doing enterprise management [as originally proposed] will cost about the same and take about the same time but will bring a whole lot of other problems that a redesign of the core services would solve.”

Dekkers said he found an economical way to achieve the solid foundation for his project while getting his client to buy in to delaying implementation of the enterprise management system. This strategy will achieve the linear form, following his parallel processes to organize and simplify the network.

Dekkers’ desire to force the project into a linear form, where problems are solved and then the solution is reached, may be difficult to achieve once he gets into his project, according to Ted Smith, vice president for research products at TechRepublic. Smith is a former Gartner Institute CEO and director of research covering IT project management issues and practices.

“The bottom line here is not whether you need to define the solution up front—you always do—the real issue is how much detail is needed in the definition of the solution,” Smith said.

Smith doubts that Dekkers’ ROI and plan will work exactly as Dekkers expects that it will, saying he has never seen an IT project end up looking as it was originally envisioned. But even if Dekkers’ plan doesn’t turn out exactly as he thinks, that will be okay because it should end up close to Dekkers’ original plan.

“The meat of the issue is how defined does a project need to be—not do you have to define the project before you do it,” Smith said. Calling on Dekkers’ bridge analogy, Smith said, “In construction, everybody can agree upon the finished product before it is built. In IT, you almost never have a clear picture of the true end product.”
Before you start a project, how well defined is your objective? How do the end results compare with how you defined your objective? Start a discussion below or send us a note.

Editor's Picks

Free Newsletters, In your Inbox