How can an unplanned work have pros?
Well, in one of my recent project, I faced a situation where I had to decide if I can accommodate an unplanned work. This unplanned work got stimulated due to technical reasons as the senior tech member of the team pointed out to a code base that needed refactoring. To find out more, read through this blog and do put forth your comments and thoughts…

Have you managed a long running product development project in a co-engineering mode where the team is highly experienced enough to understand what is good for product? Yes, you read it right ‘product’ and not project. Very recently, while I was handling such a project, we had a release that required code refactoring as one of the unplanned task. I had a small debate with this high caliber tech person. The whole explanation ended with one strong sentence. He said, ‘You can never convince the business owners to have a feature with 50-75 story points for code refactoring work.’ For a moment, I thought, ‘this is true’ and checked with him multiple times if this had any impact on the schedule. This highly dedicated tech person was not going to budge, he openly challenged that before the beginning of QA phase, he would complete the refactoring work.

From my experience, I know: “The business owner wants new features to be developed and they only look for value for money. The time to market new features is so important that, they would never agree for such change request.” However, I decided to discuss this with my SPOC (single point of contact). I knew my SPOC to be a highly technical person who understood this product/domain very well. We did not succeed in convincing for this refactoring work, but all my SPOC said was if you think there will be no impact on schedule, you are the PM and you decide ‘what is best for the project’. I knew he was also under pressure to meet the timelines. After hearing this response, we came back and thought to drop this work. But this techie was adamant and said come what may, he will work on this. This left us with no choice but to accommodate code refactoring work. We decided to leave everything on this techie who would ensure to take things to closure.

Are you thinking Agile?
With technology enhancement and experience, people become more knowledgeable and do hit a code section that requires code refactoring? Should we take up such unplanned task? As a general project management philosophy, I would not have encouraged any unplanned work. But in this case I felt why not? These are small value-add that will take the project/account to new heights. Shouldn’t we think product, why should we always limit ourselves with frozen requirement, why can’t we be agile? Will this gold plating bring success; all such queries were bothering me?

Team Dynamics and Assumptions…
The team size of 30 members including devs and QA at the ratio of 2:1 was working on this project. The functional manager and 2 other devs were working from Onsite(US). The spec was frozen and we had pretty aggressive estimates. On top of this, like any other project, there were unknowns, assumptions, impediments and risks to be looked into. So we started working on new feature development and all our prime focus was on this. Meanwhile this techie was refactoring the code base. The number of new features that were being developed was good enough for QA to focus on this testing. There were few assumptions from the code refactoring work that if we test all the new features thoroughly, we would have covered all areas of the product.

Go, No-go decision?
The dooms day arrived and it was time to go live. We had shared the list of known issues and discussed each one of these before we decided to go-live. Production Servers were down over the week-end and we had smooth deployment. It was time for the business owners to sign-off when the biggest shocker mail was sitting in our inbox, next morning. There were few changes in the core product which is bread and butter for them.

A look into Production bugs…
These changes/bugs may sound simple and one may tag them as P2/P3 issues, but this would have had major impact on all their customers. They were:

1. The order of information published in the core product got changed
2. The number of results were different (Later we found the previous version had bugs and this was actually fixed now)
3. There were missing links which use to direct the user to the web version
4. Location missed displaying the city name. It just displayed State names.

The entire product team and the business owners were pissed off and we got our morning dose from both Client and management. And the techie working on this claimed this as actual requirement and pointed towards some unassigned product backlog items and discussions. These were never prioritized and were lying in backburner.

What went wrong?

1. Lack of Test Strategy: Assumption that testing all the new features will ensure stability of their core product went wrong.
2. Communication Failure:
   1. During code refactoring work, the changes in functionality was taken up. This was not discussed with PGM (Program/Functional Manager), PM or the test team.
   2. Leaving all aspect of code refactoring changes on single person and not extracting information was another failure.
3. Code walk through of Architects or senior techies in the team was missed

Root cause analysis…
You must be thinking this blogger has gone nuts. Even after knowing such high client impacting bugs were introduced; how can there be a pro to it? If you notice the root cause for this problem, it is not pointing to delay rather it is pointing towards unplanned testing strategy, communication failure. Knowing that this code base is related to their main product; we should have strategized dedicated testing. If these bugs were caught 2 weeks prior to go-live date; we would have fixed this. A code walk-through of technical architect, peer code review would have helped.

What was missed in the process was communication with key stakeholders such Test Manager, Functional Manager, Project Manager. This led to gaps and late finding of unforeseen bugs during the Go-live phase. One week later a patch was released to address these issues. An excellent product with all new features integrated went live. All the hard work and effort to build the new features went in drain and I felt sad for the team that they did not get the appreciation for the amount of features they had built in such a short span. This was a big learning. Yes, what could have been a major successful release became a disaster.

Dos and Don’ts…

1. Do not believe in assumptions – isn’t that simple?
2. Track your assumptions and have one round of check to ensure these assumptions are right.
3. Note down your additional communication channels and have a plan to communicate.
4. Knowing client’s business and their core product, the team including this techie should have touched base regularly.
5. Irrespective of who is coding, have walk-through of code. Peer review would help.

Simple, isn’t it? What a hard way to learn this!

How to get a buy-in for such unplanned work from business owners?
Ideal situation in such scenario is to build a strong case study around this and show dollar value or revenue loss due to bug fixes, patchy code base. This will help business owners understand the need of code refactoring. May be QA team needed an additional 1 week of testing effort. Such black holes will exist in the code base and tech team along with PM & PGM should build a strong case to get buy-in from business owners. Yes, PGM’s must also be included as they are usually based out in Client’s location and can convince better. If we can show the value loss in terms of revenue or effort; it will be understood and prioritized. Even if first attempt fails, try again and wrap your learning’s and present it in such as way that everyone atleast understand this. It would definitely be ideal to work on a task that is planned.

So, share your thoughts/comments….Did you find this article interesting? Do you agree with me? Do you disagree with me? What else could have been done proactively to ensure success?

Shrinath Inamdar Life at Aditi, Project Management

What is a Metric?

Effective management of any process requires quantification, measurement and modeling. Software metrics provide a quantitative basis for the development and validation of models of the software development process.

Why Metric..?

These metrics can be used to improve software productivity, quality and overall process improvements by means of appropriate and timely preventive and corrective measures. These are essential as it provides quantifiable justification of facts and accordingly helps us re-align towards the goal.

What are the metrics that are essential for Software development?

Following are few metrics that must be applied to get useful information:

1. Management:
   1. Schedule v/s Effort Variance
   2. Budget v/s Revenue
   3. Profitability
2. Team Members (Developers and Testers)
   1. Time spent per task per person
   2. Time spent on rework (COPQ -> Cost of Poor Quality)
   3. Study of Impact Analysis wrt changes and defects
   4. Test cases planned, executed and its result
   5. Code Review Effectiveness
   6. Defects/KLOC
   7. Defect Removal Effectiveness
   8. Test Coverage

If you notice most of these metric is related to time taken for a task, code review and rework time. Very often timesheet is the most neglected area wrt process or this is the one that takes the beating when it comes to timely quality delivery.

Let’s discuss few important metric that are useful:

1. Cost of poor quality (COPQ)
   

   This is one of the metric that must be given very high importance. COPQ comprises of undesired costs which are generated as byproducts of defective and inconsistent processes.

   If one converts these numbers into dollars, it will give true information on ‘how much effort went into fixing issues’ OR ‘how much revenue was lost due to bad coding’. Having said that ideal scenario will be to have zero COPQ, but truth is every software has bugs associated with it. Most of these software products go live with known issues or bugs. These are prioritized and released as patch releases.

   Overall goal should be to reduce rework as much as possible and apply certain processes such as:

   1. Following coding standards and its checklist
   2. Logging and tracking code review bugs against the developer and using this as a measure to provide timely feedback. This way it helps individual to raise their own quality bar and reduce the number of rework
   3. Every check-in must follow coding standards, checklist. It must be peer reviewed by Senior tech force in the team
   4. Updating these standards and checklist on regular basis depending upon the new learning’s.

    

   Lot of free tools is available to ensure best coding practices are followed, such as FxCop, StyleCop, NUnit etc. Also note the cost of these poor quality decreases if you catch these early in the cycle. This metric is closely tied with code review effectiveness as well.

    

2. Code Review effectiveness (55% to 60%)
   

   As mentioned in previous section, the goal should be to catch the bugs early in the cycle. Ideally lot of these bugs must be caught while conducting code review. The industry standard wrt code review effectiveness is 55% to 60%. This means that one must catch 55% to 60% of bugs during code review itself. This means only 40% to 45% of bugs can leak through and these may be related to functionality issues, user workflow issues.

    

3. Defect Removal Effectiveness (DRE around 98%)
   

   Once the QA team certifies that the software product is ready to go live. The number of defects that can be found during UAT(User Acceptance) must be just around 2%. Let’s say during QA phase the number of bugs that QA team found for a particular software product was 400, then the number of UAT bugs can be at the max 2% of 400 which is 8.

    

   Aim should be to ensure that 98% quality is achieved along with list of few agreed upon known issues. One must keep this as benchmark and improve further.

    

4. Key Management metrics
   
   1. Effort Variance (10 to 12% max)
   2. Schedule Variance (0 to 5% max)

    

   These metric benchmarks are different in different companies. Most widely used metric range for the effort variance is 10% to 12% max. In case this is exceeding, it means Scope Management has issues and needs to be fixed. It all boils down to expectation management and applying proper estimation process. Learnings from previous retrospection must be applied to ensure success and continual improvements.

   Schedule variance, ideally should be aimed as 0% variance; which means delivering quality product on time (on the agreed upon date). These dates are initially agreed upon depending upon the scope of work, number of resources and the time it takes to build the scope, test, integrate and deploy.

    

   The list of these metric is huge. But one thing at the end finally matters is “Were you predictable wrt quality and time“. If yes, you have met the project objectives.

    

Some sample metric are shown below:

 

Case Study Project: ABC Project

Problem Statement: To build a customer portal that integrates with defect tracking database, provides content management, helps provide licenses info, download and upload relevant licensed Software and its patches.

Project Challenges: Initial 1-2 weeks of RA phase was getting dragged till 4-5 weeks. The key stakeholders had confusion on the requirements, wireframes and were debating what the best use case wrt be usability. They felt its better to be absolutely clear before development phase begins. The onsite PGM was fairly new wrt MOSS technology and had to commit to client on ‘what is possible out of the box and which requirement requires customization’. In such a situation what was committed at the end. This project was a fixed price project to be delivered within 3 months duration and with fairly new MOSS developers. Dev’s would have sat idle if we had waited for requirement to be frozen. How did we resolve these challenges and much more…to know this read further? J

First proactive action: Development was initiated much before the FS was frozen. The assumption was that 30% of the requirement may change. This means certain nitty-gritty would come up and we had to apply these changes. Technical design sessions and approach was discussed and documented. This laid the solid foundation for the team to get started in the right direction.

Second proactive action: Since requirement had evolved while development was in progress and to ensure there is uniform understanding among all the key Stakeholders, we planned 3 demos before the final release. This helped us to re-align and set right customer expectation. Early demos of the product helped these key stakeholders to decide upon what exactly they wanted. The changes wrt user workflows, changes in feature, UI changes helped this project raised a CR that was almost 30% of its initial value. Multiple benefits…isn’t it?!! J

Other critical challenges: Since development was scattered and requirement were not getting frozen, the check-ins were done in working folders. The code review happened only after 1 month’s time. This was the time when we first reviewed the code and realized that the team was way behind the coding standards. The data below speaks for itself. Check the defect numbers 35, 27, 32 and 17…

Corrective Action: Detailed code review feedback was given to individual developers. Based on this a code review checklist was prepared, coding standards were re-circulated and we walked through these standards and checklist for 3-4 hours. The checklist was updated as and when area of improvement was required by the team members. FxCop was implemented, defects/KLOC was published with individual developers and expectation was set.

What was the improvement?

Applying these simple rules such as following coding standards, checklist and peer reviews helped the team achieve better quality. Check the new defect numbers: 6, 8, 8 and 7 as against initial defects 35, 27, 32 and 17.

Well, you are right, team had to stretch and go extra mile to ensure quality standards which the MOSS Solution Architect was expecting were met. Check out the Effort variance thereafter:

Achievements: This project was delivered on time with required quality and by the end of this project; we had quality developers who were MOSS experts as well. This dev team is grown into Senior Developers and they cherish the learning’s of the project even today.

Shrinath Inamdar Project Management

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

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.

PLAN	Design or revise business process objectives to improve results
DO	Implement the plan and measure its performance
CHECK	Assess the measurements and report the results to decision makers
ACT	Decide upon the changes required to improve the overall process and implement the corrective and preventive action

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