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

IT organizations were doing well until sometime back. Subprime crisis led to fall of many banks in US and before we know, we were in recession. Though nobody knows when this recession would end, but we all hope that it would end soon. Until this happens, IT organizations are facing typical problems that are often seen during recession times such as rising bench strengths, increased costs, and lower revenues. To make the matters worse, there is uncertainty about when the economy would turn around. Hoping that recession would end soon, organizations shall use this slowdown to their advantage and should prepare themselves for the good times. First thing that organizations are trying to do is to increase the employees’ utilization by effectively training employees on newer and in-demand technologies. They are reluctant to hiring at any levels. Thus organizations are focusing on competency building internally. So in the light of cut-throat competition, building competency has to be aligned with organizations strategy derived from sales planning and operations management.

Let’s see how organizations shall go with competency building . . . .

1. IDENTIFY THE GOALS: Competency building exercise needs some retrospection before organizations take the first step. The reason being, this exercise would have been done even during good times. So organizations must examine the earlier efforts meticulously. They must find out the success rate and impact of it in various projects. Otherwise following the same approach, would yield same results. If organizations are struggling with the competency building since good times, this is an indicator that something wasn’t done right earlier. And during slowdown, it is critically important for organizations to take the right step, or they risk ending up in wrong direction altogether. Going forward, when the economy picks up, organizations that are strategic would have the edge over their competitors. Organizations must approach competency building as follows:
   
   1. Identify the areas in which the competency needs to be built:People who drive sales strategy (typically senior management) and people who are responsible for operations need to come together and align their goals. The mistake that few organizations do is that they run the competency building in silo. That way, they are never able to build the competency that is required for driving sales growth.
   2. Define the extent of competency building:They must work out the approximate target numbers in each level in pyramid. These numbers must be tied to the sales targets both in the short term as well as long term.
   3. Expectation Management: The next most important factor that defines the success in competency building is to have the right perception. Training employees in a new technology does not make them experts in one go; instead they get a quick and timely head start in the new area. The fact that every organization while hiring, look for a specified years of experience in a particular stream is true across all verticals and at all levels. If this wasn’t true you would have seen advertisements like “We need 5 smart people with or without prior experience for all levels”. Having said so, this does not mean competency cannot be built. It can be build if organizations define a good strategy and ensure its strategy meets the overall organizational goals. For e.g. management must provide for specific follow-up trainings and live projects experiences (even internal project would suffice) and see this exercise through.�
       
2. ACHIEVE THE GOALS: Once the organizations figure out their goals clearly as stated above, they must ACT to achieve the specified goals. Organization can run different specific programs to achieve these goals. One way would be to run training programs in the areas in which they need to build up the competency. Another would be to use employees available on bench to develop internal tools which are required in order to improve the organizations’ efficiency internally. This shall be done by remaining focused and ensuring that these programs are aligned with their overall goals. Organizations must work to ensure following:
   
   1. Focused trainings: The training programs should be very much focused. Organizations must do their due diligence in doing gap analysis. They shall consider the business lines they are in and also explore this opportunity in expanding their horizon in different areas. This gap analysis can be done by:
      1. Analyze earlier projects: Organizations must spend time in analyzing earlier projects from different perspectives. They must find out what went wrong and what are the specific areas they must improve upon.
      2. Analyzing earlier sales deals: Also organizations must analyze the pre-sales deals that did not materialized. Few reasons that the sales deal did not materialize could have been like no fitting resources, no prior experience, poor estimates, high cost. Focused training would help organizations to fill in these gaps.
   2. Role based trainings: Next organizations must evaluate their employees. They must get the buy in from the employees being trained. Another thing that organizations must ensure is that these trainings are role-based. This means that if an lead level employee is trained on a new technology, organizations must figure out if the same employee would be able to play the similar lead role in that new technology. To play a specific role in any technology needs some prior experience and this becomes important for the senior roles especially. This holds true for not only during recession times but also during good times.
   3. Development of internal tools: Development of internal tools, are good for all organization in various ways such as:
      1. Building competency
      2. Manage operations effectively
      3. Evaluate a technology and
      4. Helps in sales pitch

   But before organizations jump into developing internal tools, they must take care of few things to be effective:

   1. Selection of right tools to be developed: Organizations must ensure that they are investing in developing the right set of internal tools, which are really needed. When approached, every manager or head of department would have a long list of internal tools that they would like to be developed for them. After all they are not paying for this. This would lead to a bigger mess (multiple applications using different technologies with no consolidated data) later if not managed properly. Organizations must take a holistic approach in deciding what tools to be developed, what technology to be used, and their priorities. Organizations must not use any technology just for the competency building sake. This would help them in coordinating training programs effectively with greater success.
   2. Execution model:After identifying the tool to be developed and the team that is going to work on it, organizations have to make sure the project is executed in a right model, as if it is a live project for a customer. Organizations must not take any shortcuts here and swap the roles or responsibilities within the development team executing the project. For instance, project managers must not be collecting requirements if in live projects they aren’t suppose to play that role. Right set of people shall be given the right set of roles.
3. PERIODIC EVALUATION: Competency building efforts shall not go on for a long time without having any mechanism to measure the success. Their success must be measured periodically. This would be good for both organizations as well as employees. Organizations would be able to deploy new people effectively. If employees are not convinced within themselves, they would not be giving their 100%.
   

IT organiztions with an effective strategy, strong leadership and vision, would be able to build the right competency J . . .

Jagdish Malani Project Management

Let me start this blog by asking a few questions:

• Do you think the Project Manager is the role model for all the team members?
  • How often does this often?
• Is PM really respected from his/her team members?

Before I begin with opportunities of PM (Project Manager) to become a role model; let’s quickly understand what this role truly demands. This is important because there is a myth and wrong belief among various project team members that PM’s are mere coordinator and are usually there to police around them and take action. There might be some instances where Managers leave such notion.

So, who is a Project Manager?
A person who takes ultimate responsibility and guarantees for the desired result to be achieved on time and within budget is the Project Manager. A PM has an overall responsibility for the successful planning, execution, monitoring, control and closure of a project.

Well, in this blog, I want to highlight how easily a PM can get confused between the process and the goal. In such scenario, PM’s usually gets inclined towards quantifying things that does not add any value. Not sure of what else to do, they tend to occupy their time with less important activities such as metrics, spreadsheets or reports. This makes team members belief that PM is not adding any value. Team members can very easily carry these thought of their PM’s in all of their future projects. By definition, ‘project is a progressive elaboration’ and PM getting stuck with such non value added activities increases the gap between project and the PM.  For the PM, he/she is in false belief that if the project team just pursues the processes to perfection and follow the checklists; they are bound to succeed in the project.

A good Project Manager does not carried away with such stringent web of procedures; instead they are flexible enough to tweak the processes according to the project needs. A PM should always keep an eye on the business goal that is achieved by accomplishing a set of tasks/work and by a bunch of people (team members). To overcome the confidence and respect of the team members, PM has to educate the team members on various roles of the project team members including their own roles. As project progresses, PM has to measure each roles with their set objectives and not only provide feedback but also show the direction to conquer the gray areas. It’s important to ensure Managers spends enough time with each individual in the team and help them in cultivating a desire for achievement. Getting the best possible performance from each team member is the responsibility of the manager.

In a nutshell, PM must get involved in the project by understanding not only the business goal but all the functionalities of the requirement, by understanding the high level design architecture and most importantly by expediting the overall process of quality development by timely removal of obstacles and by providing directions that lead to right solutions at right time.

Good PM or leaders can thus earn special kind of respect from their team members (developers, testers, architects…). PM should be able to enable: act of thinking, strategy and leadership that positively impact the team. I am sure all of you would now agree that PM can easily be a role model which indeed also depends on his/her personality.

Please feel free to post your comments….

Shrinath Inamdar Project Management Project Management, Project Manager, Role Model

With my experience as a Project Manager, through this article, I am trying to collate what are typical best practices of project management I have learnt and what I practice in real time. This may not be the proven OR standard process but this is what I ended up doing to ensure project success in one of my recent project.

With Agile software development – one tends to associate a keyword called ‘adhoc’. But the fact is whatever the type of project is: fixed, waterfall, spiral – the agility exists and one needs to adapt and act smartly.

Recently, I accomplished a fixed priced project of 3 months duration that had its high level requirements already stated. But believe me this was as agile as any other project: with requirement changing until the end. This project had all the cycles/phases of project management right from Initiation, Planning, Execution, Monitoring & Control and Closure. These are typically called as Process groups.

How can one assure that every project they execute is successful? What are these key project management skills that ensure its success?

Let’s discuss on one of the key concept that makes project succeed or fail. Surprised! How this is just one area: well as per my experience and knowledge on project management this is the key:

“Setting right expectation to all the stakeholders at each phase of the project and at right time”

What does this mean?  Whether it is various knowledge areas or process groups: It is all about setting right expectation at right time with respective stakeholder.

Following are the key areas as per my priority list where right expectation needs to be set:

Expectation 1:  Project Goals – This typically covers all the processes, its input and output. So key point is: with what quality you want to achieve this, can you define a metric around each objective/goal that need to be achieved?

Expectation 2: Team member’s objective setting – These project metrics or goals can be achieved if one ties these to the objective settings for each team member (consisting of developer, testers…) in the project.

Once these are set – the next step is to track, monitor and control these. This can be done by measuring the metrics at frequent intervals depending upon the milestones and length of the project. Based on the information, one needs to take necessary corrective and preventive action. So, the end result would be you would re-prioritize and reset/rework on the objective setting. Some other key areas where this concept must be applied are:

Expectation 3: Setting Customer expectation – Whether it is timely status reporting or getting right information from Client: it again boils down to setting expectation with Client. This should have supporting data, reviews and feedback to ensure all stakeholders have a buy-in.

Expectation 4: Checking project progress at regular interval (at milestones) and re-setting expectation – This is the key piece to ensure that what was initially defined in scope is same as what is achieved. Getting this validated at frequent interval prevents last minute surprises and project failures.

I hope in this article, the message is very clear: irrespective of the type of the project in this agile nature; “define simple measurable steps, apply, measure and control”. You will find various jargons to illustrate this same principle: one of them being PDCA, also known as Deming cycle.

I hope this article has given some basic insight on ‘effective project management’ and information on ‘how to apply simple basic rules and ensure project’s successes’

Please post back with your thoughts and your own experience. We can debate on them.

Written by,
Shrinath Inamdar

Shrinath Inamdar Project Management Effective Project Management