Infosys IT Project Management blog discusses concerns of IT Project Managers and highlights solutions to overcome setbacks. The blog also features trends on awarding Infosys Certification for IT Project Management.

April 21, 2010

Comprehensive Estimation - An Eye Opener

Estimation is a critical planning activity in the life cycle of a project.  With the IT industry and engineering processes still considerably immature, estimation still continues to be a challenge. "It is based on estimations that budgets and commitments are made." Standish Group Research, in their latest edition, reports that more than 50% projects overshoot their estimates. What could be the reason? Well, in my thought, this is because project managers focus only on effort estimation. Various aspects like size, effort, schedule, cost, and so on need to be considered for comprehensive estimation.

The below listed points bring out some salient features of comprehensive estimation:
  1. The Size of the application provides a sense of estimates. The industry provides a variety of techniques to estimate the size based on project types (like development, maintenance and so on). Development projects make use of FP or cosmic FFP to estimate the size of the application to be developed. Use-case based estimation is also used in some cases.  FTE estimation is widely used in a maintenance scenario. More recently, NESMA FP is being used for the  same purpose.
  2. Effort Estimation considers the productivity and size.  Selection of the right productivity data determines the success factor. This productivity depends on various factors - such as people skills, process maturity, and so on. Every organization has to come up with standard productivity data for every variant of project type. They have to make use of the past data and organizational skills set and decide on the target productivity.
  3. Estimation of the Right Timeframe (Schedule) for the execution of the project is a key facet in estimation.  The schedule for a project needs to include factors - such as people leveling, critical path identification, applying crashing or fast- tracking appropriately, and so on. Identifying all important activities form the key to the success of this activity.
  4. Cost Estimation not only includes the effort cost, but also involves various cost factors associated with the life cycle of the project for budget. Budgeting becomes an important activity during the course of the project. Every modification to a requirement requires proper analysis of impact right from size to cost.

Though the above points paint a comprehensive picture, there are other dimensions as well.  For example, defect estimation, based on a prediction model, helps the project management to perform objective gating during the course of the project. It may also happen that after defect estimation, the project manager would like to revisit the effort estimation or schedule estimation. Hence, the comprehensive estimation revolves in a cycle, considering all these aspects hand-in-hand. Once the cycle is stabilized, the estimation is recorded and validated with all stakeholders.

Monitoring these estimates happens to be yet another activity throughout all the life cycle phases, as a means to understand and predict risks effectively.  Any variation from estimations have to be identified, analyzed and acted upon at the right time, so as to ensure success of the project. A well planned project is half complete. Comprehensive estimation paves the way for the execution of a well planned project. To know more details on comprehensive estimation, please enroll into the Infosys Certification for IT Project Management. This course covers the topic in-depth, providing IT related examples and case studies.

Written by Mosesraj R, Project Manager, Quality

The Agile Processistas

A project manager friend once said that  rigid processes and systems end up being roadblocks to innovation. I am sure he was wrong, but there is a message to consider - All of us grow up with CMMI  processes all around us, and by the time we start managing projects, we have KPAs  running through our veins, and we end up being hardened process geeks, or shall I say "processistas". Nothing wrong with that. These time tested processes that we religiously follow:  from requirement gathering, thru 'build' to implementation methods produce amazing results.They increase predictability, and maturity, while reducing risk,etc.  But sometimes, just sometimes, we get boxed in and find it difficult to think outside of the processes. That's when injecting a dose of "agile" into our system can make a difference. Especially when we are dealing with a world where paradigm shifts are common place.  This is exactly what we did while managing projects for a client, resulting in amazing success.

The client was in the midst of a large organizational transformation program, building their Enterprise Resource Planning (ERP) system from scratch. Before Infosys, the program was perennially troubled for over 2 years, with no deliverables to show. So when we came in for one large project in that program, we started with incomplete requirements, a business team with no confidence in the program, and stiff time-to-market and budget constraints.  The client wanted the project to be delivered in 4 months. The processistas in us took us straight to the scheduling system that told us that the client was kidding us . We did pass on the advice to the client, but if we had stopped there we would have lost multi-million dollar revenues over the next 2 years. Instead, we created a tailor-made end-to-end development process for this client, taking our regular methodology and accelerating this by applying some agile principals.  For this, we did the following:
  • Analyzed as-is process and methodology
  • Created a tailor-made development process
  • Applied innovation  to make every step of the Software Development Life Cycle more efficient
  • Educated the client
The As-Is process
The client was following a half-baked agile methodology when we walked in.  There were some obvious issues with their process, especially in the context of a large program with multiple development groups and diverse stakeholders. Some of these are listed below:
  1. Due to the lack of Requirements management, Requirements Analysis (RA) was moving  in circles for 2 years,loosing the complete trust of businesses.
  2. The starting code was built before the requirements were complete. This lead to continuous rework at a catastrophic level.
  3. Since there were many independent development groups, not having design artifacts - such as the Data Model - created immense churn in the program.
  4. Down-stream projects - such as data migration and reporting - struggled because of changing design and data models.
  5. A lack of project or program management structure, leading to a lack of predictability.
The client was then informed about the issues in their current process, and that delivering the entire program with decent quality, in a few months was impossible for for anyone. Consequently, we sported our innovation hat, and started creating a solution tailor-made for this client.

The Tailor-made Suite
After analyzing the client's process we started creating a development methodology that would work. A typical waterfall would not work, as we had to show some deliverable to the client early on to bring back confidence in the program. At the same time, given the size of the program, the diverse teams, and stake holders we couldn't do a pure agile. We, therefore, needed a strong and mature methodology, but with a dose of agile to accelerate the process and support stiff time-to-market needs.

We decided to go with an iterative development methodology, splitting the first project into iterations:
  • Initial discovery phase to arrive at an iteration plan and detailed SME plan
  • Each iteration runs from requirements through user testing
  • Detailed project plan provided at end of RA for an iteration
  • Separate teams and Project Managers for the first 2 iterations to expedite process
  • Created a strong RA process, using In-Flux, that brought back user confidence
  • Creation and freezing of Data Model at program level
  • Created a strong program management structure, including Risk and Change Management
We incorporated some 'Agile' principals into our methodology:
  • Iteration and feedback-based: Feedback from one iteration was used in the next for improvements
  • Efficient: Strived to make each stage as efficient and lean as possible
  • Optimized:  Continuous improvement at every stage
  • Strong Customer Involvement: Strong SME team identified to expedite RA. Also, continuous feedback received from this SME team at every stage
  • Continuous Integration: Work done by all development teams would be integrated fully before every release, thereby reducing downstream risk
We also spent time educating the client about problems with their process, the need for a strong management framework, and how their current timelines and plans are infeasible. After some initial resistance, the client started to realize that their timelines wouldn't work and started to have faith in our solution.

The Triumph
  • We successfully delivered the first 2 iterations, and that brought immense confidence into our solution, process and capabilities
  • We won all subsequent development projects, some from other vendors, and followed a similar methodology for development
  • The program on track to go-live, winning back business and executive stakeholder confidence
  • Multimillion dollar revenues from this client over the last 18 months. Project running the gamut, including testing, Data Migration, and Enterprise BI
  • Primary vendor for the client, and we now control over 90% of the program
  • Trusted partner of the CIO
Moral of the Story
Let's all continue to be hardened processistas, after all that's what is expected out of us and that's what really put us on the map, but let's also have an agile mindset that brings in flexibility and nimbleness - In conclusion lets be "Agile Processistas".

Written by Deepak Pillai, Project Manager, Energy Utility Services

Managing Tacit Knowledge in Projects

In software projects, when we talk about knowledge management it is usually about managing explicit knowledge.  Explicit knowledge is disseminated with the help of knowledge assets like documents, standard operating procedures, etc. Tacit knowledge cannot be passed on easily and deals mostly with implicit or unstated knowledge.  The individuals who possess this knowledge either don't know that they posses some unique knowledge that can be shared with others, or they think that it is routine and do not know the value of the knowledge they posses. This is where the need for managing tacit knowledge arises, and most often, teams realize the importance of tacit knowledge in crisis situations.

To understand better, let us start with a real life scenario. Suresh was the project manager of a maintenance project, which was running successfully for 1 year with 100% Service Level Agreement adherence. The project started with a team size of 20 out of which 13 were fresh people.

The system was developed in a legacy technology, so he had a combination of problems to tackle:
  1. Train the team in the technology
  2. Ensure that the transition happens without any glitches
Due to the effort of the senior engineers in his project they moved into the steady state and wrote success stories for 1 year. This was also due to the knowledge management practices that they adopted. The team developed Books of Knowledge on technology and the system they were maintaining. After 1.5 years Suresh had to release 5 of his senior engineers for other opportunities. The release was planned 2 months in advance and Suresh ensured that a proper transition took place. After all the planned activities were completed, the release happened. The next two days saw a flurry of cases from customer as it was the quarter end. There were some major issues and suddenly the team was panicking. The frantic and clueless team approached Suresh for the contact numbers of the engineers who left the project.

Now what could have gone wrong here, after such careful planning and meticulous knowledge management ?why was the team not able to cope up with the flurry of cases?  The answer is simple; Suresh missed a few tricks of tacit knowledge management in his project.

Some of the tacit knowledge management practices, which can be adopted in projects, are:
  • No knowledge is too less to share and too trivial not to disclose: Ensure that the team understands the importance of the routine jobs they might be doing, and ensure that such routine jobs are identified and recorded properly.
  • Rotation of tasks: Ensure that people are rotated across modules in the same project and that proper training takes place during such rotation. The team should record special cases that were not handled in the transition, and which they came to know of only after working on the system. This can be identified easily when a particular task is taking a longer time to complete with a new set of people.
  • Working with gurus: In every project, we come across gurus. This is because they have grasped the technology/system better than others in the team, or they have found a way to work smarter. Allow people to work with gurus on a rotation basis and tell them to record any steps that the whole team is unaware of.
  • Eureka mails: Encourage the team to send eureka mails, when they struggle with a task, and eventually find a solution
  • 10 min knowledge sessions: Schedule daily recap sessions of the issues encountered. A scribe should be allocated to take down the major issues. The scribe should record such issues in a daily tips repository and send out emails, whenever a major issue is solved.
From the above mentioned points it is quite clear that interaction between team members is the key to managing tacit knowledge. The team is the strength of any project. Therefore, as a project manager, managing tacit knowledge equates to being a facilitator to interactions within the team and innovating new ideas to make these interactions more productive and interesting.

Written by Lakshmi Kamala Madhusoodanan, Project Manager, Manufacturing Services 

Continue reading "Managing Tacit Knowledge in Projects" »

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter