CASE STUDY – MSA

MSA was a web-application that we developed for one of our US based clients. He wanted an application that would help him in his core business operations. In order to get started, he prepared one Ms-Word document containing very high level requirements. All the requirements were sent to our marketing & client support team. Marketing people (& Business Development team) reviewed the document, suggested some changes to client, negotiated on project cost, scope & deadlines and thus eventually this document was sent to me. I used to get a project scope document consisting of high level functional requirements and few terms & policies that client needs to agree upon. I was asked to have introductory call with client and discuss all his documented requirements on the same day I received the doc. Being very first call with client, I tried to understand all the stuff he sent to me. I had also received few conversation emails between the marketing team and him (client). These emails were difficult to understand as – “the email’s latest content were never in compliance with the subject it had.”

Despite my several attempts, I could not even understand the “basic functionalities” of the existing web-application. Moreover, the document sent by client did not explain anything about his business operations. “I started making assumptions about client’s technical abilities and his overall behavior.” I had a conference call with client and found that he is too busy to give me enough time for detailed discussion. However, he gave me enough time through out the SDLC. It may sound funny but “client used to be so busy that he used to schedule meeting calls with me very early in the morning i.e. 6 AM or sometimes 5 AM his time.”

The first call went fine but later I realized that I could not talk more about his business domain. The client had a precedent of his existing application and he wanted me to include almost everything from his existing application. Initially, as there were no resources available for working out the prototype, I worked out all the user interfaces with the help of Ms-Excel. I placed buttons, dropdowns, checkboxes etc. in different sheets, thus designed forms and tried explaining the functionality of the proposed application to client. However, client did not understand the Excel Idea. For some time, his wife thought that we will be developing application in Ms-Excel. After few days, I somehow managed to get one resource who worked out the HTML prototype. As I did not focus more on his business domain, I had to make changes several times in the prototype. Despite making all the changes, client was reluctant to approve the prototype as it did not contain all that he described in his project scope document.

During this prototyping phase, the client had a vacation plan. Client notified this to management. The prototype was incomplete however as he will be on vacation, management enforced me to get his “email approval” for few modules so that I get started with development. I was reluctant to do that as I was expecting some modules to be eliminated. This is what exactly happened when we got the final approval of the prototype. We lost all the development efforts for some of the eliminated modules.

Interpreting client’s project scope document was difficult as it did not explain his requirements clearly. For example, he wanted the application to generate few charts. He just included “Chart Report” in the scope document without any visualization of charts or the input data required for it. While discussing about such charts on phone, “he explained me too many requirements that I would never let us match the deadline.” As chart reporting had too many requirements & dependency, I asked my BOSS to have a word with him. My boss entered in the conversation and very artfully led the conversation towards a conclusion of keeping the chart reporting out of scope for 1^st release. After a month’s time and enough prototype presentations, I got the prototype approval from the client.

I initiated the project plan and assigned quick tasks to team. I had very few resources to start with. I was sure that I will not be able to match deadline with these resources. Despite requesting management, I hardly could get any more resources added till the end of the project. We started delivering the project releases to client. He found the application interesting; “however, he kept asking changes in the application while it is in development phase.” During this time, I found developers very cooperative but I had to put extreme testing efforts. We delivered the application successfully including the chart reporting. Many times, I had to explore different tools to provide technical solutions. For instance, I found out a grid component and we successfully implemented it too. I helped testing team also too create test cases, test the application and report bugs.

This project was a good experience for me. Below are few points that I discovered during the SDLC for MSA-

PROBLEMS FACED

1. VERY HIGH-LEVEL PROJECT SCOPE DEFINITION – The very initial doc I received was written by client without any technical background. It described the overall functionality of an application at very high level without any software-application visualization.
2. UNCLEAR OBJECTIVES - Objectives to be attained by Software application were unclear, not written.
3. UNNECESSARY REFERENCE - reference of existing application which was not at all a good software solution for the business
4. BUSINESS DOMAIN KNOWLEDGE - Lack of precise communication of business operations between business people and project manager/coordinator. Not enough time given for understanding business operations.
5. WRONG ASSUMPTIONS BY MANAGEMENT TO SATISFY CLIENT’S NEEDS
1. Giving him baseless and unachievable deadlines
2. Trying to fulfill his day to day basis needs instead of having a good detail-oriented plan
3. Making business assumptions without client’s consultation e.g. Client provides services to only Call Centers, but we in our techno-functional discussion, talked about FMCG shops
6. SIGN OFF & REVIEW PROBLEM - No peer reviews/sign offs, no client sign-offs for documents like SRS
7. COMMUNICATION GAP - Lack of communication between marketing team (who negotiates deadline, project requirements and initial project scope) and Project Coordinator
8. LACK OF ENOUGH RESOURCES – I never got enough resources to meet the deadline

MISTAKES MADE

1. FIRST MISTAKE - The purpose of first call is to understand client’s high level requirements and understanding his business. However, I tried understanding the documents sent by him first rather than focusing on his needs in his language and noting it down then in my language.
2. FAILED SETTING PRIORITIES - Emphasized more on working out software solution instead of understanding the business first.
3. UNNECESSARY TERMS DEFINITION - Always assumed that I understand business terms that client uses. It would have been more helpful if I could have discussed more of different terms with client during a call or maybe off the call by email.
4. Ms-EXCEL BLUNDER – Client never understood why I created Ms-Excel forms.
5. LACK OF CLIENT’S ABILITY ASSESSMENT -
6. LACK OF TECHNICAL TO BUSINESS COMMUNICATION

WHAT MADE A SUCCESSFUL PROJECT DELIVERY

1. EMPHASIS ON DOCUMENTATION – I made sure that I have all the requirements documented. Always communicated it to my team and asked them for frequent reference of it.
2. EFFECTIVE COMMUNICATION WITH TEAM MEMBERS – We strived near perfection and effective communication helped me to release what client needed.
3. APPROACH TO CODE-LEVEL PROBLEMS – Although I played a role of a coordinator and a manager, I always tried to understand the coding level problems faced by developers and suggested them a solution. Many times it worked and other time, I convinced client by explaining coding level impasse of developers.
4. TESTING PERSISTENCE – We kept putting excessive testing efforts.
5. DAY TO DAY PROJECT TRACKING – Created WBS and Tracked all the tasks.
6. VERSIONING AND BACKUP PLAN – All releases were given separate version numbers. Developers kept taking backup of each release.
7. HARD-WORK & PERSISTENCE OF DEVELOPERS – Developers adopted with all the changes as and when needed. They always tended to implement all that they are told (of course few exceptions). I found developers very cooperative.