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

Attention to Details is lifeline for a Project Success

Every time I analyzed a failure, I found a common thread responsible for causing the failure: “Attention to Details”. Ramcharan, in his book “Execution”, has recommended all Managers and business leaders to practice this attribute. Here’s the excerpt from the book.

“You get the impression (implicitly), that it is about doing things more effectively, more carefully, with more attention to the details. But nobody really spells out what they mean. To understand execution you have to keep three key points in mind:
• Execution is a discipline, and integral to strategy.
• Execution is the major job of the business leader.
• Execution must be a core element of an organization’s culture.”

It is very hard to internalize this; practice this principle for success. I have seen that if you are able to do this you will become the most successful person.

I was reviewing a project issue. The project was managed using Agile Scrum methodology. We finished a sprint and the customer found some basic issues with the code. The coding practices, agreed between the customer and the vendor, were not adhered to. When I asked the PM, his reply highlighted the following reasons::
• The team underestimated the task
• We got input late from the customer
• The customer had approved the demo
• While completing the demo, the team hardcoded certain things
• The team completed the work on time and delivered
• The quality aspect was not included while considering the completion date
If you sit down and look back, you will find that this is not unique. This happens every time we face some challenges. If you dig deep into the situation you will get replies like “I asked X and he told me that he would complete it, etc., etc.”

Let us look at some of the issues in this case. Before I preach, the principle let me confess “Execution is very difficult. Building the culture takes a lot of time and is also impacted by the surrounding environment. However, if you understand and internalize the principle, you will succeed in the difficult task of execution.”

How do we find issues with code? We all know the answer – “Code Review”. How we achieve effective code review without getting into each aspect of code? Some questions like the ones mentioned below may be helpful.

1. Who reviewed it?
2. How much time was spent on the review?
3. How many bugs / observations were found?
4. What reference documents were used for review like checklist, guidelines, etc…?
5. How many lines of code or pages of document were reviewed per hour?
If you ask few of them or a combination there of, I can guarantee you, you will know the effectiveness of the review. Based on your observation, you can take course correction measures before it becomes too late. One can ask many simple questions like these and can unearth the truth. “Execution is not about asking and reporting; it is about finding, exploring and helping people get into right mind set.

I think I have used simple words to explain the principle of “Attention to Details”. These questions will take a different form depending on whom you are dealing with. It will also change with the maturity of your subject. All people are not alike and they do not need the same treatment. What I am advocating here is to apply this principle differently depending on maturity of the subject.

I think this principle can get deep into our strategic thinking. This applies at each level in an organization. It is very core to our culture. If we do not have deep understanding and cultural alignment, I fear, the company is likely to oscillate like a pendulum between two extreme ends called “Success & Failure”. Sustainable success demands attention to details and its internalization into working culture.

In the Wonderland of Quality Certification

I was a student of engineering. I have often heard student’s talk, “what principles are taught in class room and what get’s implemented in life are two different things”. This is because of the failure of implementation. I have a different opinion on the subject. I have always found that whatever principles are taught, they can be applied in totality in practice. The gap is often found in understanding and putting the principles in simple steps for implementation. The art of putting a principle in simple steps for implementation and the passion for implementation are the two keys for success. This is same as having an Engineering degree and being an engineer. I studied engineering and regularly scored high grades in Design, Applied Mechanics etc. But my work life began in Industrial Engineering field. I never practiced Design principles in my life. In practical sense I have an Engineering degree but I will not call myself an Engineer. To become an Engineer you need practice, an art of applying the principles in your practical life.

If I look at software engineering and quality movement, I often think the industry is generally suffering from similar “Degree Syndrome”. CMM, CMMI and ISO are the standards which have brought excellent principles in life. Many companies have graduated and have passed the examinations; the certification process. Rarely companies have applied these principles fully and reaped benefits. All these standards give you short of curriculum. The practitioner has to understand the principles, pass the exam and practice the art of implementing in real life. First two things always happen but the practice is always a victim. That’s the reason; many companies having CMM level 5 certifications are not able to produce consistent results.

Malcom Gladwell in his book “Outliers” has talked about a practice 10,000 hours to become expert in any field. I think this principle applies perfectly in quality implementation as well. In order to make the process seamless with the workflow, the company needs a practice of 10,000 hours or more. Practice has to be in such a way that it can be synthesized and can create a learning experience too. Project Managers often tell, “Let me complete the work then we will do the documentation”. If you hear such words in any company then you should conclude that the company lacks many more hours of practice before it reaches the level of maturity in applying the principles which the degree; certification has provided. The result will never come until one has attained a perfect integration of process in work flow. The work and process have to be seen as a single entity and not two separate tasks. As long as they are seen as two separate tasks, the effectiveness of process rigor will be farfetched.

I would like to give a simple analogy of process integration with work. Let us take a payment transaction in a privately owned company. The payment assistant normally makes payment on authorization of the payment. There is a process of request, authorization, verification, payment and finally acknowledgement. The person making the payment considers all these as a single process of payment. Even if the owner asks for 10,000 rupees, the payment assistant creates a voucher and gets his signature or signature of his secretary before making any payment. This is a perfect integration of documentation with the workflow. You find such process implementation work flawlessly.

I therefore suggest implementation is a bigger task then getting certification. One needs to get out of “Degree Syndrome”. Getting a degree is the first step. Implementation of the principles needs understanding of the principle, putting them in simple steps and finally nitrating with the overall work. This simple principle can act as a guide for process implementation and therefore leads to success. Just ensure that the basics are being done, they are integrated with work, documentation is not separate than the work; you are bound to succeed.

Role of Project selection in building a successful company

I remember one of my Professor’s during my MBA days; once he gave us a powerful explanation on ‘Option of Choice’. During that time, one of the exams was close by. Typically students were used to the habit of answering five questions out of seven asked in the exam. Unlike other Professor’s, this professor was a little different and would never give options in the examination. When asked, “Father“, will we have any options this time? He replied, you will have a few of them. You can answer all 5, 4, 3, 2, 1 or don’t answer anyone. This short narration taught me the value of options in life. When I started working I found this short story to be of immense value. At every step of our lives we are confronted with several options. We may choose a few or let all go. The freedom of choice helps us to define the road ahead in our life.

Quarterly reporting has forced the company to just look one quarter ahead. The revenue targets and reporting to investors force company executives to dilute their freedom to choose an appropriate option. In hard times this becomes even more complex and the company executive tends to pick up “everything” which comes in front of them. This brings about serious consequences. In my long career path, I have come across such situations several times. May be dropping them could have lead the company to prosperity and growth.

I would like to share a case which was a result of wrong selection. The case demonstrates that how pseudo teaming happens when everyone in the management team says a yes. As such affirmative response gives a positive image to the participant. The whole team joins to cover up the failure and takes pride on great cooperation. The debate is whether such event is an example of great teaming up and co-operation or should this be viewed as team’s inability to arrive at the right decision in the beginning; this would have been profitable for the company and brings focus towards the goal.

The client was building a product which was running behind the schedule. The client had an urgency to expedite the work and meet release deadline. They wanted a vendor to take up some portion of their work and also help them in completing their work. The high level requirement was shared. The initial study of the requirement and sizing exercise indicated that it was not possible to complete in the given time frame. The client believed that if the vendor puts 3 qualified resources onsite, the job can be done. It was more of a feeling and did not have any back up of any scientific methods.

Sales team was constantly under the pressure to meet budget numbers and acquire new clients. Although the initial discussion on sizing was leading to a no-bid situation, they wanted to work with other operation division which agreed to work with them and complete the work in the given time frame. The result was simple and pleasing for everyone. A SOW was signed against the scientific estimation, based on a set of people who said yes to the unrealistic propositions. There was a sense of winning a new order which lead to a mood for celebration.
An onsite Project Manager was identified. She had working background in testing where as a substantial portion of the work was development. Meeting tight schedule was the key for success. Two developers were hired from the market. The three persons constituted the onsite project team.

It was hoped that on the success of this phase the subsequent phase moves offshore. The company was expected to give a fixed price bid for offshore portion. The offshore Manager was asked to help the Onsite project team. On first scrutiny of team’s capability and skill gap it was found that the team was not capable of delivering the contracted outcomes. This note was sent before the team assumed work onsite. The Manager controlling the activities along with sales believed that this was the best option in a given situation. The team went ahead with the onsite work. The activities went on for around 6 weeks. The outcome of this can be easily guessed by anyone. The client terminated the project. It was a LOSE-LOSE situation.

This event isn’t unusual - in any company. We all commit mistakes. It is important to learn from mistakes and not repeat the same in future. The success and failure depends on exercising the option of choice. Denis Waitley says;”Forget about the consequences of failure. Failure is only a temporary change in direction to set you straight for your next success". Choice always comes in life. Going on a right path helps to create a sound work culture, brings focus in operating teams and drives better results. Let us argue that management starts rejecting such opportunities. It will bring focus in sales team. They will start looking for right opportunities. Teaming up is very essential in today’s environment for success. Probably the team started defining the “Teaming up” in an inappropriate sense.

This short case tells us a lot. Few of the lessons are:
1. Requirement assessment is the key to project’s success and profitability. Even under pressure, compromising on basics may not lead to success. I think the proper understanding of the situation is important. We should also work with stretch goal.
2. Taking every piece of work is putting your company in a troubled position. It prohibits bringing focus and growth. Saying ‘NO’ requires courage and conviction for success.
3. Technical feasibility of doing work and risk assessment should be treated as separate items. Balance between risk and appetite to take the level of risk is essential.
4. Teaming is the key to success. Teaming compromising functional boundaries leads to failures and provides a pseudo teaming feeling.
5. Role of devil advocate is very important. This brings a culture of discussion and looking at all aspects of the opportunity before a decision is arrived. The hierarchy or prevailing culture may be a deterrent in creating a proper climate for devil advocate’s role. The leadership should provide appropriate climate for devil advocate. Their contribution in helping to take a sound decision cannot be undermined.Whether the projects are small sized or large sized, every project must bring about appreciation, intelligence and a good business sense. To achieve our goals we should have a well planned Project Selection Process.

Delivering Quality

Software Development has gone through a lot of transformation over the last few decades. Many practices have evolved. A lot of metrics have been collected. Project Management software’s have been used to plan and track the project execution. Many new practices have come and gone by. New Practices keep on coming. A lot of change has happened in the lifecycle area. Agile is the BUZZ word at this point in time. The question is, has the industry delivered quality consistently? I am sure many one of us will come up with an answer “NO”.

There could be various reasons for not delivering “Quality” consistently. The industry has grown at astronomical pace. This has led to the lack of maturity in the practices. The industry will mature one day. The implementation of projects will become more predictable. What should we do in this transition phase – Maturing Software Industry? I have learnt a simple principle which I would like to share with you.

The software best practices are meant for delivering consistent quality. The principles are known to all. This is not a rocket- science. But most of us have struggled in implementing them successfully and thus couldn’t reap the benefits. I suggest here with a two phase formula for a quick result:

1. The Long term success & Consistency: The best answer would be obtained by following the best practices in requirement management, design, implementation, testing and deployment. I wonder if programmers shall ever be able to develop a set of bug free codes. If it happens then the tester communities will be unemployed. This certainly will impact sagging job market of a country like US and growing Job market of a country like India. Thanks to the effectiveness of Programmers, the testing job has been growing. The developers should continue trying hard for bug-free codes which would eventually lead to elimination of testing work. Think; if they code perfectly and implement all functionalities flawlessly, then at the crack of dawn our dreams shall come true. Practice for improvement will lead to better and better development and reduction of cost. Elimination of testing is still a farfetched thinking.

2. Deliver best to the customer in short term: Since the elimination of testing work or reducing the same to minimal is much more than a dream. We need to have some mechanism which produces better results. This may not be a very cost effective solution. But I have seen this helping win back the customer’s confidence. Unless we win customer’s confidence, work will not continue. Therefore, for point 1, – it is essential to keep going. The suggestion here is to divide the project team into Two teams
a. Development Team
b. Independent Test Team
The test team should be fully empowered and given independence. The team should report at a much higher level than the Project Manager. All testing best practices should be followed. I’m a witness to this and have seen this giving the best results. It helps in filtering the defects before it goes to customer. You have to incur additional cost to fix the bugs. But you are buying the customer’s confidence in the absence of best quality development. Unfortunately, many companies are doing this and striving for near flawless development. This is the right strategy to endure in today’s software industry.

I have noticed tremendous resistance by line managers to implement independent testing in each and every case. Such practices give a pseudo feeling of loss of authority. People tend to forget that “deferring problem” is not solving the problem. I have seen some techniques like Coaching; Training in testing, vigorously implementing this practice will help a lot. You may decide your own way to tread the path to success.

Create an Independent Test organization, carve it out from total project and implement. You will enjoy customer blessings. If you keep on doing point 1, you will continuously keep on improving profitability over the years.
Peter Drucker has rightly said, "The single most important thing to remember about any enterprise is that there are no results inside its walls. The result of a business is a Satisfied CUSTOMER."

This shall help in delivering Quality consistently.

Mindset Matters

Each one of us has experienced many projects successes in our professional career. We have also come across situations where project goes through a tough time. We all would agree that the most common scenario is when the Customer complains The Project team gets into a syndrome; I will name this as “It’s Customer Fault Syndrome”. It finds a cause which is external to it; may be it has to do with some action or elements at customer’s end. Whenever a problem occurs, some causes are found which points to the pre-identified cause. Sometimes the cause may be valid. I would argue it gives the team, tremendous power if they get out of “It’s Customer Fault Syndrome” and start looking inside out.

Let us take a case for discussion. Due to privacy issue, the data available to us was always dated. Sometimes we came across a situation where the testing was constrained due to dated data. The defect was difficult to produce. Our team did not look at the alternative ways and took an easy path. Think; if the team members would have looked for an alternate way then I am sure they could have found some alternate (BEST) solution. Instead the team preferred to continuously stay in “It’s Customer Fault Syndrome”. This wasn’t helpful.

There was another situation where the team had developed the software under discussion from ‘scratch’. The software was under maintenance mode. Whenever the customer found many defects, the team came up together to identify the defects. The team would classify the defects as Existing defect, Change Request, etc. The team went an extra mile by identifying the change requests but the Change requests were never agreed by the customer in a joint meeting. This way of classification gave the team a pseudo-satisfaction of not committing too many defects. This continued to go on for a while. You can imagine the amount of noise being generated; we were on the verge of losing the work. Management realized that they were under “It’s Customer Fault Syndrome”. Finally they decided to come out of it. Initially a lot of explanation was required. There was also resistance in the team. But the decision was to be taken. Both the causes mentioned above were got rid off. The goal was to own all the defects. The team discussed them and very soon, we came across a situation where improvement was visible.

This is not a rocket science. But unfortunately many times we become a victim of this syndrome. I suggest that whenever you see many fingers shown towards customer, look at it. Let us not forget customer pays our pay check. Start looking inside-out. Try changing the situation democratically. If it takes time; think of other options. Your success depends on coming out of “It’s Customer Fault Syndrome”. You will get good solutions. You will succeed.

Success- is all about Mindset. It’s the Mindset which matters.

Finding Simple Answer to a Problem is the Solution for Project Success

Recently I finished reading a book “Outliers” by Malcom Gladwell. I found the book to be very thought-provoking. The author has attempted to identify some causes which leads to extraordinary performance by some great individuals like Bill Gates, Bill Joy, LN Mittal etc. The author opines that for a person to become an expert in any field one needs to do 10,000 hours of practice. It is impossible to achieve such practice level without dedication, hard work and focus. It goes without saying that one needs to have proper opportunity to practice and last but the not the least, one also needs the Grace of God – “luck”.

I was thinking about our –garden-fresh Software Industry. This industry is full of smart individuals who want to rise very fast. In that process the “Practice” of 10,000 hours gets missed. We have to run development organization with a set of individuals having an average industry experience of around 3 years. The Resource Mix is very popular in Indian IT industry and time and again Management looks for a reasonable RMI (Resource Mix Index) to optimize the profit margin. These have implications for quality delivery. You will not have an “EXPERT” in your team. The result is inconsistency in quality of the product delivered. CMM culture in software organization has brought the discipline of Root Cause Analysis (RCA) in the companies. Often RCA is done for improving the quality in a project. Beautiful Fishbone Diagram is prepared. {The Fishbone Diagram identifies many possible causes for an effect or problem. It can be used to structure a brainstorming session}. Everyone is “Happy” after identifying the root causes for substandard delivery. They follow these but the problem keeps shifting from the origin. The problem does not get resolved. This means something is not right.

I would like to pinpoint my experience in looking at Root Cause Analysis for reducing defect injection while development. You will get frustrating experience when you look at the causes recorded in the Defect Database. You will find that most of the recorded causes are irrelevant. They do not lead to simple solutions which can be tackled for improving the outcome. In some cases it might, but generally it does not. It’s not that the team does not understand the concept. It is because of the team’s ability to understand the problem in simple terms. I have spoken about lack of expertise in the team due to environmental issues.

Management has to put an effort to optimize the expertise available in the company. I recommend the following steps:
1. Within a group of 10 development resources, the team should have a person who has the following qualities.
· Ability to guide the team
· Ability to go to the root cause.
· Ability to break the defect reasons in a set of simple causes which can be acted upon.
2. Identifying the causes is a continuous exercise. We have to start with a set of well thought causes and club sundry under “Miscellaneous”. Miscellaneous should not account for more than 20% of the problems. If miscellaneous accounts for more than 20% of failure then you need to revisit the causes listed and get to the bottom of it.
3. Look at 80% defined causes. Remember they have to be simple like “Exception Failure” and “Cosmetic Defects”. Cosmetic defects sometimes appear generic but if you take up with the stake holders and define a set of guidelines then programmers can be trained on them. If you are able to identify simple common causes then you know that the solution is simple.
4. Once you come with remedial actions, do a mapping of actions with the causes. Remember actions cannot be 10 or -20.It has to be max 5 or preferably three.
5. Continue these steps. There is a very common saying, “It is easy to preach than to practice”. Similarly, Let us not forget preaching is simple but execution is the toughest. You have to keep an eye on the target and keep on trying until perfection is achieved.

Sometimes it could be a challenge to get a Key resource or a Kingpin. The PM or the trailblazer has to take the responsibility by helping the team to either identify a Key resource or to get one. If you do not have an ALL Set person then look for someone who has the passion and willingness to learn. Coach him\her. It works.

It reminds me of a Hindi couplet (stanza)

“Karat Karat Abhayas ke , Jad mati hot suzan
Rassi abbat jaat ke Shil per parat Nissan.”

“If one keeps on trying time and again one will succeed like a soft rope which creates a deep impression on rocky walls of water well.”

Theres an American proverb~ “Success is a ladder you cannot climb with your hands in your pockets”. It points to the Importance of Practice on Success as found by Gladwell without specifying the magical 10,000 hours mark.

Creating Meaning in Project Work

Associating Meaning with what you do is critical to your achievements on the project. Let us read a famous story about cleaning work in a Pharmaceutical Company.
This is a story about attitude towards work in a Public Sector and a Private Sector company. Large Public sectors are known for its bureaucracy whereas Private sector are known for its agility. A sweeper joins a Public sector. On his joining day, he goes to see the departmental head to understand the job responsibilities. When the new employee introduces himself, the boss says, “I know, you are XYZ joining this company as a grade IV employee”. Without offering him a chair, the boss continues: “Your duty is to sweep the floor and keep the toilets clean”.
Now imagine yourself in sweeper’s shoes. What could have happened to your pride? In Public sectors sweepers are known for absenteeism from their work. They are also looked upon as habitual drunkards.

Now, Lets take the case of a well managed Private sector. The same sweeper joins and reports to his department. As soon as he enters the cabin, the boss smilingly asks him to take a chair. He welcomes him with a cup of tea. He explains to him “We are in health care business. Even a small particle of dust might kill a patient. Your job is very important and you have to ensure that the drugs being manufactured here should not carry even a single dust particle. Your efficient work will save many lives. The ability to create meaning in the job makes a great impact that you get a sincere, devoted employee who takes extra precaution to maintain cleanliness around without being absent for a single day. If you go to a public sector the situation is totally different you need not ask where is the toilet?.

On a personal note, I do not believe in Public sector Vs Private Sector. Instead you have difference in attitude in a well managed company Vs a bureaucratic company. Let us look at the meaning behind the job. In the second case the manager was very successful in creating a meaning in the job of the sweeper. He could provide the purpose of his existence. The meaning in the job is the ultimate thing; it applies equally to all walks of life. Be it a software project, a construction project or a routine work of sweeping the floor.

Let’s take an example from the Software industry. The company got a project from the Head Quarter (i.e. an Internal work). The work was to build a Saas based system for core business of the company. The technology to be used was .NET and the database to be used was SQL. If you happen to ask a team member about his/her job profile, you will get a typical answer like “I am developing a software using .NET & SQL as database”. Don’t you think this member is doing same thing what the sweeper was doing in the first case? The answer is “Yes”. I think we rarely look at the project and work for creating a meaning in it. If you are able to create a meaning and the resources are able to correlate with that meaning, it gives a huge boost to the morale of the team. The motivation level of the resources working on the project also goes up, which contributes to project success.

Normally in Software Company people do not like working for an internal project. This product was being built first time in the world for Localization market. It is a Saas based product. The product is very core to Chairman’s vision. Let me attempt giving a meaning to the work the team was doing here. I am summarizing the same in two bullets:
• The team is creating history in the world in Localization space and empowering the users to have the best of the breed solutions for their problems.
• The team is working for Chairman of the company

I believe this meaning creation has tremendous impact on the team morale. When I discussed this with the team, I noticed the glow on the faces of the people. I saw a sense of importance among the team members. I would like to state that one of the KRA’s of a Project manager has to create meaning in the work the team does. This gives birth to a sense of Pride in all people. It brings empowerment and finally makes a project successful. It is simple and does not costs a thing but “It works”.

Sensing Gap in Requirement Process in Software Maintenance work

Gartner predicts highest CAGR of 8.9% in Application Software Support Services in next 3 years. For any Software company engaged in off shoring, application support services provide continuous revenue stream and is very important piece of work. We often come across situations like lack of understanding of domain of the client. Domain plays a very important role in understanding the requirements, and their effective elicitation and interpretation. I have seen many projects going down due to flaw in the requirement process particularly in maintenance space. Sensing gap in the process at the early stage helps in making project successful.

This reminds me of a famous story of a surgery by a qualified doctor. A patient signed a contract with doctor. The patient was operated to remove gall bladder stones from his stomach. The gall bladder stones were picked up and shown to the near and dear of the family, they all were excited. When the patient came out, he was dead. The Doctor had signed for removing gall bladder stones. That was the requirement. It was never discussed that patient should recover after the operation. Can we consider such operations successful? Certainly not. This explains the type of requirements namely Explicit Requirements and Implicit Requirements. During requirement elicitation process, the explicit requirements are spelled out and the implicit ones are often missed out if the requirement team is not experienced in domain and in art of requirement gathering. Such situations lead to troubled project & troubled relationship. The question comes how do you sense such gap at early stages?

I will share some symptoms which should alert a project manager and should remind him to focus his attention to details and bring the best practices in requirement gathering for software maintenance work.

1. Waiting for Clarifications: When you dive deep into project review and come across situations of “Waiting for Clarifications”, get alerted. There is a very fine line between “Seeking Clarifications” & “Lack of Understanding”. Look into some specific situations. You may get surprise in terms of lack of knowledge of your team on the subject.
2. Low First time Right: First time right is an excellent metrics for measuring your maintenance ticket delivery to the customer. If your first time right is lower than 70%, look into the requirement process.
3. Low productivity of the team: The low productivity may be due to various reasons. One of the most important reasons is wasting time in interpreting requirement and getting into a loop of understanding.
4. Disagreement on CR Vs Defect during defect washing process: Sometimes customer can be unreasonable. But most of the times such situations arise due to gap in requirement understanding.
These are some of the indications. The moment you come across one or few of them in your project, look at the requirement gathering process under microscope. You will come up with one which is most suitable to your company in the given situation. However, I would like to share a few best practices in this area.

1. Most of the outsourcing engagements are structured as onsite-offshore engagement. Often an onsite co-coordinator is linked to the engagement. Giving requirement gathering task to onsite coordinator or business analyst is a good practice. He/she captures the requirements, gets validated with the customer and then shares with offshore team for understanding and development work. This process saves a lot of time and takes care of some of the symptoms mentioned above.
2. As mentioned earlier, domain plays a very important role in requirement interpretation. Let us take a look at domain skills of our team. Some generic knowledge with each team member and presence of at least some domain specialists is a great help. This practice has helped me in some projects. It can be stated as taking your boat from troubled waters to safe waters.
3. In some of the cases you may not be able to put a coordinator who is able to elicit requirements. It may be a good practice to explain requirements to the team including testers. This helps in open discussion and understanding the requirements by all team members. If any requirement clarifications are referred to the customer by the onsite coordinator. This helps in reducing gaps in requirement accuracy. Involvement of test folks at an early stage helps in delivering a quality deliverable.
I would argue – one of the very important roles of a Project Manager is to sense gap at an early stage of the requirement process. If you happen to see gap (Smoke), work towards finding out the root of the fire. It helps in extinguishing the fire and makes the project successful by following simple steps.

Life Cycle selection plays a crucial role in Project Success

As software professionals, we often encounter questions on selection of development lifecycle for a given project. Ten years back the industry talked about Waterfall, and at most iterative as recommended model for software development. Today Agile is the talk of the town. Many companies are getting into the bandwagon of Agile. The client, development professionals, and sales professionals in the vendor company have picked buzz word of Agile world. It is good to understand the Agile principle but at times it could be costly to force-fit every situation into Agile. Since Agile is the buzz word today, very often we come across situation of force fitting any development work in Agile model. Is such force fitting beneficial?

Let us look at the Agile development model. Agile is based on 12 principles and six values. The values are Commitment, Focus, Openness, Respect, Courage, and Empowerment. The principles summarize the world of changing requirements, frequent deliveries, working software and bringing all stake holders like product manager, business user, analysts, programmer, and testers together towards the success of project. If you look at the values they can be implemented in any scenario. These values are great and bring unique advantages whenever applied. The principles help in differentiating Agile from life cycle model like Waterfall. For instance, changing requirement and frequent delivery is corner stone of Agile where as Water fall believes in frozen requirements and large delivery. There are situations where these models can have its advantages and can provide superior results. For instance if requirement is frozen, applying Agile will not be beneficial. At the same time if requirement changes are visualized frequently, going with Waterfall method will lead to confusion and mistrust between client and the vendor. Therefore it is useful to have a right Development Lifecycle for a given work.

Two important parameters for selecting a life cycle are Requirement Stability and Technology Maturity. If technology is evolving and so is the requirement, Agile will give the best results. If requirement is frozen or is likely to have minimal changes, technology is proven; it is better to adopt Waterfall.
In my early programming days, “C” was introduced as a programming language. I think the power of C was its simplicity. C has only few concepts (Chapters) unlike languages like COBOL or FORTRAN. Similarly the power of Agile is its simplicity and set of universal values which make the development environments vibrant, brings transparency in interaction. Let us not forget that one can implement these values irrespective of a life cycle chosen for a development work. I have seen these values are proved to be beneficial for project success.

I will recommend you to internalize these value set for your development team. Value is like a religion. It is hard to change as it takes a lot of time to change. So the companies should attempt internalizing these values. The values set should at least contain all the values prescribed by Agile Manifesto. There is no harm in having a larger superset of values specially suited to your organization. Once you are through with them, Agile life cycle implementation will become easier. The simple framework suggested above can be used for selecting a life cycle. These two things can go parallel as a maturity improves. If you have achieved maturity on values and did not get many opportunities for Agile life cycle implementation, you will be better off once a real Agile project appears in front of you. Even though you do not have a chance to have enough projects based on Agile life cycle, the maturity on values will pay for itself.

To sum up, Agile has a strong value set. It is useful to internalize them irrespective of you do Agile project or not. The life cycle should be selected at least based on the Requirement Stability and Technology Maturity. There could be other dimensions for selecting life cylcles besides these two. A right selection of life cycle helps in optimizing the Project value to the stake holders and makes the Project Successful.

Managing Requirements Risk is key to Project Success

In recent days the IT industry has seen strong companies becoming stronger and the tier II or tier III companies struggling for keeping its identity intact. For managing reasonable growth, particularly for listed companies it is important to show growth quarter on quarter to please the Shareholders, analysts and other stake holders. Such reporting brings accountability on Management. Accountability is highly correlated to ability to deliver results. Needless to say 10-15% companies have established ability to deliver, others struggle to define themselves, find unique place and establish differentiators. In absence of clear differentiators it is hard to manage growth. The market pressure puts a strain on sales engine and sales tend to get into a Pseudo Differentiator Syndrome. The company starts differentiating itself on Lower Fixed Price even for a relatively undefined set of requirements. Unfortunately customers tend to fall in the trap of lower price and committed delivery. At the end of the day as the requirement is relatively undefined, it leads to a series of commitment failures which leads to unsatisfied customers and loss of business. It does not help anyone; neither the vendor nor the customer.

Let us spend some time in understanding the Fixed Price work. Fixed price work brings accountability on part of the vendor and it gives a delivery commitment to the customer. Obviously, the requirement needs to be well defined and understood before such a deal is struck between the client and the vendor. Invariably, both the client and the vendor gets into a trap. Vendor gets a tendency to differentiate itself on Fixed lower price even though the requirement is not clearly outlined. The client gets into a trap of going with the vendor who gives a go-ahead all the time. This is dangerous as it leads to Project failure, unsatisfied customer and loss of business for the Vendor.

Risk is a part of any business. There is no reward without risk. Therefore, while accepting a job a reasonable level of risk is necessary. Any business cannot prosper without taking a risk. I suggest the following three factors framework which will arrest the situations described in foregoing para.

1. Requirements Uncertainty: Variations expected in requirements.

2. Skill unavailability: Measures if the vendor has right skill sets to deliver. High unavailability means lower delivery possibilities.

3. Time unavailability: This dimension measures the expected time duration by the client vis-à-vis available time to deliver the requirements. High time unavailability means high stretch being committed.

A project scenario should be evaluated either on High or Low parameters. Low on all three parameters is the best situation for a vendor and also for the project success. A High on all three is a “Death Trap”. Vendor should avoid such traps. Invariably vendors get into such traps following “Pseudo Differentiation Syndrome”. High on all three is not taking risk rather it is committing suicide. Other combinations of High and Low can be examined by decision taken based on the risk appetite of the vendor.

Similarly, the client should evaluate project scenario’s on above parameters and match its assessment with vendor’s offerings. A close match will lead to a healthy relationship and project success.
Requirement Risk Management is the key to project success. The three factors described above are three critical dimensions for evaluating risks associated with a requirement.

Needless to say understanding Requirement risk and managing them appropriately is the key to Project success.

Five Steps To avoid Project failure

In a competitive business world today, Project failure happens more frequently than we normally think. Some failure leads to analysis and learning, others initiate a blame wave in the organization. The failure is expensive; it costs time, energy, money and customer confidence. Too many failures can derail the growth engine from the track for ever.

One can avoid failure by following five simple steps:

1. Understand the customer:
It is said Customer is the king. Whenever we go to a king, we have to look at his long term success. King may be in hurry some times. Consultative selling demands to understand what the king is looking for, looking at his explicit and implicit requirements; provides a suitable solution. One should look at long term proposition and customer success. It is important to understand the Critical success Factors (CSF) of the engagement. Once you understand the CSF’s, work out your strategy to address all CSF’s. Sometimes, people get tempted to see money on the table and try to take what customer has budgeted even though the solution may be much lower than what is available on the table. This does not help in long run. If you want customer confidence, better be truthful to his purpose and long term goal, and help him realize his long term goals. You will emerge victorious and forge an everlasting relationship.

2. Manage Requirement effectively:
A solid Requirement elicitation is like constructing a solid foundation for a building. A tall building cannot stand unless the foundation is very strong. Many times we compromise on requirement capturing phase. Domain knowledge, skills in unearthing requirements and differentiating explicit and implicit requirements are important skills to be invested in requirement capturing phase. One may follow any suitable practice. It is important to capture, understand, communicate and validate requirements with customer. Any compromise at this stage costs heavily and contributes towards project failure.

3. Communicate Clearly:
Marriages break due to lack of communication. So is the project. It is important to identify stakeholders in any project and work out communication plan. The progress, challenges and successes should be communicated transparently. Communication helps in building confidence in project team, helps in identifying potential problem at an early stage and come up with appropriate solution. Communicate, communicate and communicate…

4. Manage by doing basics right:
I have done many project reviews. Whenever I get complicated answers for my questions, I assume that the guy has not understood the issues. He is shooting in dark. If you do the basics right, you will succeed. The basics have to be very simple and to be understood by each stake holders. Jargon complicates and basic solves. Just to give an example if you could set up simple processes for unit testing, code review, design and requirement review you are bound to succeed. Do not look for compliance, look for basic steps, are they being followed? Ask how reviews are done? If you get simple steps, you are done. Success will greet you.

5. Manage Team Skills:
Software Projects are resource intensive. They need skilled resources. In an ever growing market, getting resources with particular skill set is a herculean task. I have rarely seen a perfect fit for all required skills and team skills in any project. Therefore, it is important to follow a simple step of doing a skill gap and plan for bridging the gap. This helps immensely. You can’t have perfect situation. Work with what you have and deliver the best.

If these five simple steps are followed, the project failure can be avoided. It is simple, it works.