Since the SSD earns most of its revenues from fixed-price projects, our management processes have to be tight and our quality processes have to be excellent to allow us to avoid overruns and retain profitability. In this respect, we are in a small elite minority in an industry which primarily operates on a T&M billing model.

We have tried to document some of the lessons we have learned from our projects and how our management process has evolved.

• The Level 2 specs sign-off helps us communicate better with the cusotmer before development commences
• The Task Tracking Table helps us avoid unpleasant surprises with schedule overruns
• The CR tracking system allows a systematic process for resolving issues with the customer during the final acceptance of a software system
• Remote relationship management processes allow us to develop software for customers we have never met in person.

Most development projects start with a specification-writing stage, after which the client is expected to review and sign his acceptance of the specification document. This is followed by solution design, which is followed by coding.

We have found that this is often inadequate, specially for interactive business applications. We build an initial conventional specifications document, which is accepted by the client. We call this our Level 1 specs document. But we do not place much importance on this sign-off. Based on this, we do a preliminary software design and build a complete set of mock screens, making their appearance and behaviour as close to the final appearance as possible. The business function officers of the client organisation go through the screens on their computer, enter mock data, and discuss each field of each screen with us. This gives them a much better idea of functionality than a specifications document. We take a Level 2 sign-off after freezing the screens.

Benefits: This benefits the customer because he gets a very real "feel" for the software application that will be developed, and therefore even a customer inexperienced in software development processes finds he can appreciate the specs given. It benefits the SSD because it sharply cuts down the likelihood of scope creep, misunderstandings and overruns later.

Once the detailed design of the application is complete, the next three steps are pseudo-code writing, coding, and unit testing. These steps are highly parallelisable, and this is where the largest team size is deployed. At this point, we use a task tracking table to measure progress.

This table contains a list of all the individual code units, The expected effort estimate in person-days of each task (e.g. pseudo-code, coding, testing) of each unit is recorded. As each phase of each unit is completed, its actual days of developer time are recorded. This is compared with the expected effort estimate for that task, and gives us a clear continuous measure of the effort overrun and calendar time overrun. This table can be processed to generate a daily summary of the percentage completion of the entire project and the percentage of the total estimated effort (measured in person-days) which have been consumed till date. Comparing these two figures gives a clear and early warning of projects heading for overruns.

With our task tracking process, a daily report is just five lines. An example is given below. (WD = working days; PD = person-days of effort)

This example shows a picture of a project beginning to get into an overrun. It shows that 35% of the budgeted resources have been consumed but only 31% of the work has been completed till date. The fact that 35% of the resources have been consumed in the first 29% of the working days may be less of a problem.

Benefits: This benefits the customer because he does not see unexpected time overruns one week before the expected delivery date. It benefits the SSD because the management team can get alerted within one day from the date any project slipup starts.

When the project enters the User Acceptance Testing (UAT) phase, clients usually begin to submit change requests (CR) and bug reports to the development team. These are tracked in a CR tracking process. We have used software for this purpose, but we often find that a paper-based tracking process with a pre-designed blank form on paper works as well.

Each Change Request is graded by severity:

• cosmetic changes, like some text needing to be highlighted on one screen
• functional change, where the specfication the development team worked with is different from what the customer believes he needs
• bug, a flaw which clearly generates incorrect results
• critical error, which affects the entire functioning or stability of the system

Each CR is then picked up, executed, tested, demonstrated to the customer, and closed after customer sign-off. The CRs are picked up for execution in the order of their priority. Some CRs have commercial impact on the project terms.

Benefits: The CR tracking system helps steer the project to a close, by addressing bugs in a systematic and time-bound manner as well as resolving functionality and specifications differences between the customer and the development team.

It is always difficult developing software for a customer who does not have the opportunity to meet the development team frequently. The communication barriers throw up special challenges.

We apply a maximum visibility strategy to counter these barriers. We invest a lot of additional effort into communication to ensure that the customer never feels out of touch with the development team. Besides, all the measures discussed in the previous sections, e.g. Level 2 sign-off, are applied to these projects as well.

The SSD applies the following special processes to achieve this goal:

• Weekly teleconferences: These are undertaken with or without there being any need for a specific week. These routine teleconferences go over the past week's work, give indicative commitments for the coming week, and discuss any unresolved problems which were not resolved by email till then. These conversations help a lot in building confidence and generating visibility for work in progress.

• Email management: All email communication with the customer is tracked by the Project Manager, and any unanswered questions that the customer had sent in any email are tracked and followed up on. The Project Manager ensures that all such queries are answered in a suitably detailed response.

• Prototyping site: Most of the software applications built by the SSD have browser-based front-ends. A prototyping server is set up on the Internet, in one of the server racks the company operates. On this server, the infrastructure team sets up a replica of the software stack the application will need. The development team is then given a semi-automatic mechanism to upload all completed modules or units, immediately after unit testing.

  This allows the customer to connect to the server over the Internet using secure connections and encrypted channels, and test each unit of software development, even if it in alpha-testing stages. The customer's observations are then discussed both over email and during the weekly teleconferences.

• Guided walkthroughs: Whenever a module of the application is ready for UAT or even ready for intermediate inspection, the team leader for the module uploads a running copy of the software, sits in front of a computer with a browser, and enters into a long tele-conference with the customer. Using this setup, he guides the customer through the prototyping site, and "walks" the customer through an entire sequence of screens, with realistic data.

  These sessions are completely open-ended, and allow the customer the opportunity to ask the most unexpected questions about the sizes of files, ownerships and permissions of directories, and the method to make changes to the configuration of the running system. Our teams have found that this is the most powerful method to give the customer a clear idea of the project progress.

• Minimum team size: Based on experience, we have found that it is important to have a minimum team size working on a software project for remote customers. If the engagement size is really small, then the resources needed for managing the overheads of communication exceed the resources deployed for the development work, leading to cost structure imbalances.

All these measures together ensure that our remote customers do not suffer due to communication gaps or lack of face-to-face meetings.

Pages: Prev 1 2 3 Next