Schedule Slippage – Root Causes

“The single most important task of a project: setting realistic expectations. Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure.”- Futrell, Shafer

Introduction

With global and competitive market, it is very important to launch a product or service in the market on time, ahead of competitors. Definitely, timely launch depends on on-time-completion of the product development projects. Project planning has lots of challenges to overcome in order to finish the project on time – right from schedule predictability, envisioning future/possible risks and coming up with mitigation plans.

This article talks about some of the challenges, often faced in the Software Product Development industry that causes the schedule slippage.

Schedule slippage: Delay in the project completion from its initial estimated date of completion.

Each project plan will have a planned completion date (NRA, RA), and a bounding box or upper limit in schedule. Nowadays, it is a common practice to have three dates associated with any project plan:

• Non-Risk Adjusted (NRA) date: Project completion date assuming no hurdles – Ideal conditions.
• Risk Adjusted (RA) date: Project completion date assuming some risks will come on the way and will need extra time to attend to them.
• Bounding Box (BB) or upper limit: The upper limit on the project plan before which the project has to be finished under any circumstances – Generally decided by the top management based on product/services roadmap and launch in the market.

Under ideal circumstances, any project is scheduled to complete by NRA date. Considering some risks that may come on the way and would eat some time off the schedule, the project should be over by RA date. If the risks were not envisioned and hence not planned well, then project may get delayed and would complete after RA date. Project completion crossing the RA or upper limit is neither good nor expected out of a well-planned project.

Root Causes

As we always plan for a project to get over before RA date, seldom is the case it happens as expected. There are multiples reasons for schedule slippage, right from improper planning, lack of resources to unplanned requirements and rework that eat away vital time off the planned schedule.

A typical project development process – Each project will have a team (development, testing and other functions) that will work through a process (requirement analysis, schedule estimation, design, implementation and testing) to deliver a product to the customer/end user. Each entity that participate in the project – directly or indirectly affect the schedule.

From the development process, we can identify the items that can cause delay in the execution of the project – for example, misinterpreted or unclear requirement adds up to completion time, unavailability of development tools or resources can prolong the project duration. Various processes like schedule estimation, detailed design and product development if not executed skillfully, may significantly blow up the project cycle.

For better understanding all these possible causes that may result in schedule slippage are categorized .

Let’s have a detailed look at the root causes of schedule slippage category wise.

1) Schedule Estimation: “The key is not to prioritize what’s on your schedule, but to schedule your priorities.” – Stephen Covey

For a project to be executed on time, it is very important to have it planned very well. Any mistake in project schedule estimation reflects as delay in the project completion from its deadline. There are several factors that contribute to improper schedule estimation:

· Underestimation of technical complexities: At the start of the project, many of the team members may not have thorough knowledge of technical complexities and hence their estimation would be incorrect. Sometimes it may so happen that the person giving estimates for a particular task is having no idea about the technical challenges involved in carrying out that particular task. You might hear, towards the mid/end of the project life cycle when the task is not finished on time – “Oh, I didn’t know that this feature also requires 5 more tasks to be done!” or “I was thinking this task to be so simple, but I under estimated it!”. · Lack of Design/Big picture: It is important to have a bigger picture / overview of the complete project to understand how a particular module/feature would fit in to complete project. Product or system level design helps in understanding the interfaces among other modules and the required coordination for product assembly and hence, a better insight into the work involved. Often, estimates without focus on detailed design tend to deviate more from the actual time taken for finishing the job. · Integration Testing: While making a project plan, testing also needs to be accommodated in the schedule. At times, the unit testing or testing done by individual contributors on their module is taken into account but not the system level testing. Toward the release, when all the individually tested modules are brought together, a system level or integration testing is a must. Having the time for integration testing not accounted in the overall project schedule will cause delay in the project completion.

· Unplanned dependencies: Project planning is not only about breaking the project into minute tasks and managing them. A well-planned project schedule also needs to consider certain unplanned dependencies. Some of these are:

o People: Optimum utilization of human resources calls for same set of people working in multiple projects. A person may not be available to work for currently planned/assigned project due to extended/unplanned work in another parallel project. Another issue related to people could be unplanned/unexpected attrition that will affect the project plan. Time is also lost in mentoring of new member by a senior (more experienced) person which goes unaccounted if not planned.

o Tools & Equipments: Project can be delayed if team is waiting for release of upgrade or procurement of any vital tool (hardware or software being used in the project) or if the equipments required for development and testing are not available. “We had a 3-months project for validating our existing solution on new product platform using customer DUT (device under test). We had to wait for the DUT for nearly 1.5 months as it got stuck in customs. After getting the DUT, we realized that it’s been damaged partially during transportation. As a result we had to ask for another DUT and whole project took more than 5 months to get finished.” – I am sure that such cases will be quite familiar to many organizations. Other reason for timely unavailability of tools / equipments is that they are shared among various projects to reduce the operating cost. Any unplanned dependency on their usage or wrong assumption about availability of these shared resources would cause delay in the program. Team members might have to work on shifts to optimize the usage of shared resources which can cause reduced work hours and/or productivity loss and results to schedule slippage.

“I was waiting for Matlab license to be released by another person in the team but he left the office without doing so and I lost 3 hours figuring out what to do?” – is it something you faced before?

o Other programs: If multiple programs have deliverable dependencies, then delay in one project will have cascaded effect on other projects, which directly or indirectly depend on its deliverable. “We got delayed because we had to wait for a critical UI component from the framework project team” or “We didn’t plan for bug fixes for a component which was supposed to be delivered defect free for our usage” are the common scenarios for delays in program which are dependent on other program deliverables. Parallel programs may affect the schedule of your program in a different way as well – Sometimes, management changes the priority of the programs running in parallel. If your project is considered as a low priority one then there might be lack of resources assigned to your project that may result in schedule slippage.

· Beta releases: How many times we seek feedback on our product during development? And how often we allocate time for it? It’s important to plan beta releases if we desire to have our product validated by expert users or lighthouse customers during development. Getting feedback from beta customers becomes important especially when their requirements echo that of a mass customer base. Process of giving workable releases to customers, collecting their experience, having their feedback analyzed, and then incorporating in the final product version takes significant time.

· Risk mitigation and plan B: Every project will have some or the other risks. These risks can be of varying severity and probabilities. While making project plan, it is important to treat the risk individually based on their severity and probability of occurrence. If high probable risks with higher severity are not planned with their mitigation plan (or plan B), they will have huge impact on schedule deviation from planned one. As in one of the previous examples quoted, getting a DUT on time for validation was a risk. Had there been a mitigate plan (plan B) like – Validate with other DUT or if DUT is not available here, let one developer travel to customer’s place and finish the validation on time, the schedule slippage would have been avoided.

2) People: Ultimately, projects are executed by people who may not be skilled or talented. Hence, looking for perfection in projects involving human beings may not be a feasible thought. Certain unpredictable and hence unavoidable issues under this category are:

· Poor leadership: Before thinking of project execution, it is project planning that actually would set the platform of success. Execution of the project depends on its team while planning is taken care by the project leader. The project leader is expected to have enough technical know-how to understand the project goals and to the details of the tasks involved. Poor leadership and superficial knowledge of assignments often results in invalid effort estimation and ad hoc task delegation causing stress and possible delay in project execution. People leading the team are also responsible for keeping the team spirit and motivation level upbeat. Poor personal commitment due to lack of motivation results in loss of productivity and may cause schedule to slip. Another reason that adds up to delay in projects is inability of leadership team to track the schedule progress and take the correction action.

· Attrition: If the project duration is large and job market is hot, it may be difficult to retain people in the project till its completion. Attrition may further delay the completion especially if the person leaving the job was in critical path. A person leaving the organization would leave a gap in the project that a new person may not fill immediately, which in turn causes sudden reduction in the task force.

· Learning curve: When ever a new person or team member is included in the project, he or she may require some time to understand the project to keep in pace with other members. Learning curve is needed for new team members, joining the team either due to attrition or due to any specific technical competency requirement. · Context switching: In smaller organization or groups where people work on multiple projects simultaneously, it is important to have some buffer for context switching. A person planned to work in project ‘A’ for two hours after a gap of two weeks, would take more than scheduled time to complete that task. Gap of two weeks and the fact that he or she was involved in other project would require some time for the member to get back to the context of current project. · Global development teams: In an era of globalization and outsourcing, it is common these days to have development team distributed over different geographical regions. Project plan needs to account for different time zones and working culture. You might expect an input for your task on Monday morning your time but it may be Sunday late evening for that person and finally when the input arrives, you might be on your way to home after work.

Sometimes schedule estimation might go completely wrong if you have not understood the work culture of the region your teammate belongs to – “In my previous work, I was given a task to be completed with a heads up that its very critical task and needs immediate attention’. When I asked my project lead how many days/hours I have for it, I had been time for 2 weeks for high priority and ‘immediate-attention’ work.” Definition of ‘urgent’, ‘high priority tasks’ changes with culture and region.

· Communication Issues: People communicate differently. If important issues are not brought to the notice of the team members, or are not escalated on time, the entire project may suffer. Often fear of embarrassment stops team members from reporting issues faced during execution leading to more time being spent on that task that can easily be executed additional help.

3) Customer Involvement: These issues are quite serious if customer or end users of the product are involved in the development phase. Understanding customer’s priorities, defining your expectation from their involvement needs to be clear and in agreement with both the parties.

· Expert user testing: In the beginning of the project, expert user testing cycle needs to be planned. Process of giving builds or releases for testing and collecting their feedback, analyzing and incorporating them in your product takes significant time which, if not planned, can delay your program. · Timely feedback: “I got feedback from customers for features, delivered in development milestone-1, after milestone-5 towards the release. These feedbacks are critical but now I am worried how to incorporate them without affecting the schedule.” It sounds like a common problem. Incorporation of feedback from customers needs to be planned well taking a commitment from the customer. · Product requirement specification review: Having a product requirement review planned and executed will keep you on right track throughout the project. Reviewing the requirement specification will avoid requirement related defects fixing which otherwise would have delayed, the project.

4) Ambiguous Project Requirement: For any project to be initiated, the first thing is to have requirements for it. In the product development life cycle, requirement phase acts like a foundation. Clear requirement or vision for the project navigates the team to success. However, requirements may not be clear at the time of estimation and may result in delay in the project completion. Issues related:

· Evolving specs: If you are making a product based on a standard which is not yet matured or still evolving, you are more prone to have this risk. Frequency changes in the specs will change the requirement for the project during different stages of product development and team will continue to work on something that is not yet evolved. This results in rework that would delay the project if time for dealing with these changes is not accommodated in the schedule. “We developed an algorithm and hence measurement that was based on certain industry standard. Towards the release of the product, the specs changed and our measurement was no more valid. We had to redo the algorithm to reflect the changes in the specs. This caused our product release delayed by 2 months.” · New requirements: Sometimes new requirements are added as the project evolves towards completion. Implementation of new requirements is not planned at the beginning of the project and hence is not accounted in schedule. Adding new feature without revising the schedule may result in delay.

· Untold expectation: Requirements from the customers may be of two types – implicit or explicit. It is important to have the requirements well documented. Implicit requirements needs to be better defined and documented to avoid any confusion towards the end of the project. Customers may not describe their requirements related to system performance, memory issues, user interface quality and usability but they are very keen on providing feedback in those aspects once the product is given for expert user testing. If we are not clear about such requirements, out design might not address them. Addressing them towards the end of the project may call for design changes and extra work that would delay the project.

5) Unplanned Tasks / Reworks: Bounding box for the project is set by higher management and often lack buffer for unplanned task(s). Having more of unplanned task that creep up at different phases of project can cause schedule slippage. The unplanned tasks or rework may arise due to:

· Sustaining work: In smaller organizations, some of the project team may also be responsible for sustaining / customer support of existing products. These unplanned tasks, which come on event basis, related to customer support are always of high priority. Excess or prolonged sustaining work may take resource out of the planned project causing a potential threat for schedule slippage. · Defect fixes: Defects are bad as they degrade the product quality and consume extra time/effort to fix them. It is good to have testing of the intermediate releases of the project to find and fix defects sooner in the development life cycle. If the fixing-cycle for such internal-milestone defects is not planned, then either the project is either going to slip or product is going to be of poorer quality. Poor programming skill of the team, not adapting to modern programming practices and having ad hoc development processes may lead to higher number of defects which would take more time to fix then planned and cause slippage.

· Task spillover from previous milestone: Tasks that are not completed in previous milestone, due to whatever reason (inefficiency, vacation of the team member, resource crunch etc), will have to be completed in the next milestone thereby increasing the load on the team. If adequate buffer is not planned, these tasks spilled from previous milestone over to next, can delay the project. · Requirement change / refinement: Requirement changes during the product development will result in rework of what has been previously done with first version of requirement(s). Addressing changes in the requirements needs extra time and effort and may cause schedule slippage. In some cases, the requirement from customer is misunderstood resulting in wrong system design and implementation. Additional, unplanned time is lost in correcting the design/implementation which causes schedule slippage.

Conclusion

On time delivery is the challenge software development companies are facing globally. To have a complete control over estimated schedule, it is very important to identify the elements in the development cycle that cause schedule slippage. This article uncovers and explains the root causes of delay in programs using examples from real world. Having an insight to the root causes will help the program managers to make good decisions to avoid future schedule slippage.

Source by Mukesh Soni