Software development projects can be a challenge from start to finish. At the beginning, we don’t like to take the time to plan well, and we rush through the business requirements since we assume that we already know what the client wants. We have fun initially with the design work, but then we discover the technical environment is more complex than we thought and start getting headaches. Coding is a blast, but then we have to do the testing as well, which starts off okay but becomes tiresome. At the end, we're just looking to get the darned project done, but there is one more challenge ahead—implementation.
Implementation is often called deployment and, for purposes of this column, the two words are synonymous. There is no single way to implement an application. It depends on the characteristics of your project and the solution. Some implementations are as easy as saying, “We are now live.” This type of implementation can work when the solution is brand new and you're developing and testing in what will become the production environment. In these cases, implementation is just a state of mind: One day the solution is in development, and the next day it's in production.
At the other extreme are implementations that might be projects in and of themselves. For instance, you may have a software application that needs to be deployed to your division offices around the world. This could take months to accomplish and require a full lifecycle of planning, analysis, design, etc.
When you think about implementation, you should always start by understanding the complexity involved. If the implementation is relatively straightforward, there is no reason for elaborate implementation processes. So in this column, I'll focus on strategies to consider when you face complex or lengthy implementation requirements.
Many of the best practices around project management have to do with early planning. In fact, if your developers question the need to spend so much time planning, you can point out that one planning consideration is identifying the complexities of implementation. If the implementation were large enough, you would actually start by creating an Implementation Strategy in the Analysis Phase. This document would describe the overall approach to implementation, the scope, assumptions, risks, etc. You can make some fundamental decisions here in terms of how the implementation will take place. For instance, you can decide whether you'll be running in parallel tests during implementation or whether the system will be down during a particular phase.
The next time you would think about implementation is in the Design Phase. Here you would create a lower-level Implementation Plan. If you created an initial strategy document, the Implementation Plan would simply fill in many of the details. If you didn't create the strategy document, you would need to mentally start at the higher level to understand what you want to accomplish, but then you would quickly jump into the planning details. Among other things, the Implementation Plan is used to set the overall timeframe for implementation, identify who will be doing the work, list the organizations involved, and estimate the effort and duration parameters. If the implementation involves new processes, you'll need to account for how you will train the users and who will do it. If the implementation needs to occur in multiple locations, you'll describe the overall sequence. It's important to note that the Implementation Plan provides detailed information that can be shared with your stakeholders and project team. However, it is not to the level of the actual work plan.
Build the implementation work plan
So far, we've completed an Implementation Strategy (during Analysis) and an Implementation Plan (during Design). However, we still have to actually build the work plan activities for deployment. This should be done during the Construct Phase. At this point, you have already worked your way from high level to low level, so your remaining work is to actually define the activities, dependencies, timing, responsible persons, etc.
When you actually hit the Implementation Phase, you'll have a work plan ready, and you can be reasonably sure that it will accomplish what you need, since you've validated a high-level and low-level plan already.
Communication is key, as always
In addition to planning, the other critical element of implementation is communication. (Again, we're talking about a complex implementation. If your implementation is small, you might just throw the solution into production and explain what you did if there are problems and the client screams.) If you follow an approach similar to what was previously described, you will have been communicating all along. The Implementation Strategy is meant to focus on the process from a client perspective, and should have their approval before proceeding. The Implementation Plan should be circulated to everyone involved, so they are covered as well. You just need to communicate continually to reinforce the messages and make sure everyone is ready when implementation occurs.
If you don't prepare an Implementation Strategy and Plan, you still need to at least communicate with people as far in advance as possible. My experience, for instance, shows that there is a natural point of friction between the development staff and the infrastructure staff because implementation details are not communicated, or else they are communicated too late. How many times have you seen a team ready to implement a client-server application and then realize they need the workstation support group to install the application on the desktop? Of course, if the support group is not prepared because of a lack of communication, they will not be a happy bunch. Other friction points include failing to give advance warning to the Help Desk when applications are deployed or when major changes occur, since they may take many support calls from users if things don’t go right. A third concern is that the development team discovers too late that the server environment needs changing to handle implementation. Again, this is normally not a problem if the need is communicated well before implementation begins.
Planning and communication drive a successful implementation
In this column, we looked at implementation from a methodology view. The key points are to plan early and communicate often so that there are no surprises. Even the most complex implementations can be managed successfully with top-down planning and good communication. On the other hand, even the simplest implementations can be screwed up with poor planning and poor communication. In the next column in this series, we'll look at some of the details of implementation and what specific things to consider and watch out for.