Project Management – Planning is Agile 

Software estimating and planning is all about determining an appropriate schedule or deadline. Planning happens in the initial phase of the project life cycle and once committed to a schedule and stated quality, one is bound to meet the agreed accepted criteria. ‘Not really’; it’s not just that, isn’t it? So, what is planning? Can we state that “Planning is agile” and happens through-out project life cycle? Let’s find out various issues of planning and how we can ensure proper planning.

Planning is one such process group that is an ongoing activity. Planning plays an important role in various knowledge areas such as Scope planning, Human Resource planning, Cost planning, Quality planning, Communication planning, Risk Management planning, Risk Response planning.

The plan must be revisited whenever there is any changes or impact to any of the above mentioned knowledge areas. Other important areas when a plan must be revisited are:

• Change requests and Accepted changes
• Missed Scenarios being identified
• Requirements getting elaborated progressively
• Change in either dependencies, assumptions, risks or mitigation plan

Lets dive deeper:
Planning process involves finding an optimal solution to the overall product development. In the initial phases of the project, we may feel x number of features can be developed in y months and we can deliver the product on a certain date say 15^th Dec 2009. But as per Barry Boehm’s cone of uncertainty: in the initial product definition phase, a project schedule estimate is typically as far off as 60% to 160%. After the requirements are clearly written; the estimate might be still be off by +/- 15%.  Knowing this, we still make commitments such as the product will be released on a certain date. But this does not mean we do not commit on dates. Variance within accecatable range of +/- 10% is good; provided such impacts are known well-in-advance and informed. Often we miss informing this variance factor in advance to all necessary key stakeholders and hence creating unhappy clients.  

Let’s understand why it is important to inform all relevant stakeholders.
Clients would have committed to their customers based on our commitment on release date. They would have planned user trainings, preparing marketing campaigns, arranging necessary logistics for go-live etc. Any changes to the release dates without prior notice will impact their plans and thus creating unhappiness and dissatisfaction. As PMs we are responsible to set right expectation.

A good planning process supports this by:

• Reducing risks or uncertainty
• Supporting better decision making
• Establishing trust and conveying right information

 As PMs , some mistakes that we make, or at least I have made are:

• Activity based planning…
  We go by activity based planning and thereby losing the focus on feature priority
  • Once we are into activity based planning, we go by what is good logical flow w.r.t. development and ignore feature priority. This way we can easily lose focus.
  • If an activity was planned for 4 days and subsequently developer finishes it in 2 days. We take the stick and usually penalize the developer for giving padded estimates. Worst, we start assuming that the developer would complete tasks earlier than planned
• Assumptions, Risks or Uncertainties…
  Ignorance to assumptions, risks and dependencies often brings in late surprises that are not initially envisaged, and thus not estimated. This results in schedule slippage and in turn may call for dropping an important feature to meet the scheduled date.
• Multitasking…
  We often expect our team to multi-task. While planning this, the resource usage goes quite close to 1.5 or 2 times. This is one of the planning activities that is often ignored. Multi-tasking means context switching and productivity loss of team members. There are occasions when one can be highly productive when multi-taking. For example: Execution of a back-end job to load 1 year of data in parallel with other development activities. Care needs to be taken to identify if multi-tasking is possible
• Gold Plating…
  We all want to impress our clients and sometime choose to overdo by taking up stretch goal features or refactoring work into scope. When deep into design and development phase, we often hit roadblocks and identify areas that require refactoring. This can easily drift our initial vision and result in main feature being ignored. Instead of creating such tasks as in-scope features and we often tend to please our clients.  This type of work where one tries to please the client is called as gold plating.
• Setting Expectation & Prioritization…
  Between gold plating and business priority features, we often lack convincing the business owners on non-functional work. Such refactoring work which is technical in nature and as such does not add functional value; will not be given green signal. It is technical team and PM’s responsibility to provide necessary reasoning for bringing such work in scope. The time spent on rework when converted to dollars, the spent will be better understood. Such detailed analysis on dollar saving by refactoring work will be well understood and prioritized.
• Missed Scenarios & Impact Analysis…
  With requirements getting progressively elaborated and lack of understanding in the initial phase; we may face missed scenarios that are not initially estimated. Care needs to be taken to mitigate these risks and have plans to reduce the impact of such missed scenarios. Good plan usually has 5-10% contingency reserve and should take care of such misses. Careful categorization can help us identify all the change requests along with their estimation.

All such accepted changes, missed scenarios, risks and its mitigation plan, gold plating tasks, implied need tasks (such as default performance factor, providing LP – launch plans, Code review time, unit testing and bug fixing time, integration & bug fixing etc) must be updated in the plan. Few other important activities that are implicit and must be considered during planning are:

• Availability of resources along with their leave plans
• No. of hours available (hours/day)
  • I usually take 6 to 6.5 hours/day. Remaining time is used up in understanding the sprint backlog item, its design, in identifying various low level scenarios, getting clarifications to all the impediments. Since, we cannot add contingency reserve (as 5days) as one of the line items in the plan (mpp); the hours/day needs to tackle this need. 
• Getting business priority right for all the features
  • Listing all the sprint backlog items and its estimation
  • Identifying impacted area, dependencies and unknown area as line items
• Integration of Microsoft Project Plan 2007 works very well with TFS and assigns ID’s for all sprint backlog items.
• Tracking of each sprint backlog items story wise or sprint burn down by person wise helps

To avoid most of these common mistakes mentioned above, PM need to ensure consistency in watching risks, assumptions, dependencies, elaborated scenarios and changing the plan regularly. These days we rarely see waterfall projects to call out planning process as a one time activity. Plan changes all the time and hence is Agile in nature. The benefits of agile planning are multifold:

• Having early realization of business priority or value
• Regular feedback to ensure quality and provide the right solution.
• Early detection of risks
• Collaboration – tools like TFS and SharePoint play a very important role

 Before this blog takes different direction, let me stop here. Please feel free to write your comments…

Shrinath Inamdar Project Management