Let's face it, software configuration management can be downright overwhelming, and its
complexity can challenge the most organized project manager.
When The Standish Group conducted research to analyze the successes and failures of software projects, they found that 8 out of 10 projects are unsuccessful. Furthermore, nearly a third of all projects are so poorly executed, they are nixed before they are finished.
The Standish Group research pointed out in its top ten attributes of software success included project planning, clear statement of requirements, and user involvement.
It is important to approach complex projects with simplicity in mind. A few guiding tenets in your approach can help make these projects manageable manageable.
Here are five "Ts" that can help you devise a common sense, yet effective approach to planning your projects:
1. Today (vs. Yesterday)
With every month that goes by, technology changes. With such change, workers can be located anywhere. A dispersed project team is more common now than ever before.
Some recent research stated that approximately one-third of all those surveyed, had
worked at home within the past month. The rest of the research also indicated that if they had not worked at home they were working at a client's or another place of business, or in their car, at an airport or some mobile location.
The dispersed team should be accommodated in your project planning. Your processes and tools should operate under the premise that location of your team member's matters much less today, than yesterday.
2. Tool Selection
The team needs the right tools. Consult team players to find the right attributes of the technology tools that you'll use to manage your configuration project.
Because there are hundreds of tools to select from, it is important to develop a list
of attributes that are going to best suit your working conditions and environment. Ask questions, such as, how accessible will my team be to the tool? What is the cost of such a tool? What are the terms and conditions of the license involved with any technology tool? What is the risk of selecting a certain tool? How much latitude will team members have in using it? What are the terms and conditions of the trial period and just what exactly is your trial offer?
Also, beware of free tools. Often there is a temptation to utilize "free tools". While it may appear that they are free because they are available on a trial basis or on a regular basis, we all know that you will eventually pay for it one way or the other.
Avoid free tools. "Free" is a misnomer, as these tools require time and cost to configure.
When you run into problems with these tools, there is no technical support to call and you could well be right in the middle of a complex project with nowhere to turn. What was supposed to be a free tool, can become quite expensive. It is rare that a complex software configuration management project can be managed with a freebie.
Traceability will allow you to trace most any action in your project effort.
When evaluating your tool selection as discussed earlier, you may want to compare
the traceability functions of different tools and see how suitable they are to your specific needs.
Like the control room of a space shuttle launch, when a problem arises, the team needs to trace it back to a root cause. Then, attack and fix that problem.
The better your traceability, the more control you will have when trouble arises. Poor traceability puts you at risk to be stuck in the mud when a glitch arises with no known origin. Traceability should help pinpoint who, what and where the root of the problem is associated. Such information provides control. Control provides quality. Quality, of course, affords a project winner.
An ability to create an audit trail is a valuable thing. Even more valuable is a capability for anybody on the team to view the entire project effort at any given time to see and even report on its progress.
A simple snapshot of the progress of any configuration management project should
be simple, understandable, and accessible by all. This allows a dispersed project team to be informed and work towards a common goal with their subparts understood. It