Importance of Set-up Phase in Project Success

Most of the software companies have matured Project Management processes. Generally Project Management has the following phases:
1. Project Initiation
2. Project Planning
3. Project Execution
4. Project Closure
Each of them has its own importance towards the success of the project. I would like to discuss today; the special importance which Project Initiation or Set up has on the project’s success. I would also like to address on the areas where we get caught in meeting the process requirement syndrome and are not able to capitalize on the process benefits from set up process.

The term “Set Up” is taken from Manufacturing, where before each batch production a time is spent for preparatory work. For example lathe machine can do various types of activities. It can turn; it can create threads and many more activities. Each of them requires a particular type of set-up phase. I have never come across a machinist skipping the set up phase or just not thinking through and doing a set up relevant for type of parts he would be manufacturing. However, in Software Engineering area, we all have “Initiation” or “set-up” as a phase. It describes certain elements but invariably the same is not followed in spirit but rather complied within words. The result is inconsistency in delivered quality; Customer dissatisfaction and lost projects. I will highlight on the two examples; one each of a successful case and another case which could have been done better.

We had a project where around 200 Stored procedures had to be documented for intended use of users. This Project will have a different life cycle as compared to a development project where we talk about Requirement Gathering, Analysis, Design, Coding & Unit Testing, Integration, System Testing and User acceptance. Every company may not have a pre-defined life cycles for the work mentioned here. This case was different than a software development case. Initiation elements were mapped for the requirement and a definition was brought for each item. For instance Unit testing could not have been applied in a classic sense here. However, a more relevant unit testing was thought of like a mapping of the technical document to the code base. This becomes a mandatory step for the developer. Similarly, each and every element of the Set-up process was mapped; brainstorming was done with team, SQA and the client. A final blue print of the customized set-up phase was evolved, which was implemented throughout the project. The result was completing the project before scheduled time and meeting 100% quality expectation. It would be wrong to say that only set-up played the role. But one thing which goes without saying is, “Good set-up was the foundation to Quality delivery”.

We had another instance where the customer was a small company and Agile was a buzz word influencing their decision on life cycle selection. The team was new to agile world and there was no onsite element during the life cycle of the project. We did set-up as a process but I think we left a lot of holes in terms of implementing the same in spirit. Some of the items which could have got more attention in the beginning are mentioned below:
• Work shop on agile for the team
• Establishing the ceremonies of agile between customer and the contracting company
• Simulating Team skill required and working for filling gap
• Defining standards explicitly like coding standard, UI standard etc
Some of them were done but not in spirit. The result is struggle during the project implementation.

Many times we mix the technological requirements and commercial expectations together. I recommend in keeping them separate and evaluate each aspect of technological needs. In today’s world, if you want to grow then you have to be aggressive and innovative in your approach. Compromising with the technological requirements will elude success. These could include items like set-up items, transition time frame, transition location, on-site presence etc. We should evolve a solution which is the best and meets aggressiveness and innovation elements. After doing that bring the cost element. The price to change to the customer is a bigger call and may get influenced by many other factors. One should exercise caution in getting influenced with pricing requirements leading to compromise on technical issues.

Therefore my recommendations are:
1. Follow a set-up process in sprit. Do brain storming upfront. Customize the phase to suit project needs.
2. Evolve a technically viable, aggressive and innovative solution. Pricing considerations and customer expectations should be brought in later.
These are some best practices which help in succeeding.


Typically, what I have observed is the process is followed but enough effort is not made to address all issues and life cycle is not tuned to the requirement of the work