About  Contact  Help      

Newsletter - Feb 2016

For up to £250 Bonus for sports, use our exclusive bet365 Bonus www.abonuscode.co.uk Claim your bonus and start betting at bet365 now.
PM Essence
Product Spending and Implied Strategy

                                                                                                                               - Rich Mironov

We make day-by-day or story-by-story prioritization choices without noticing the cumulative impact of those choicesbut they add up. Seemingly small transactions can lean all in the same direction. For instance:


• Sales teams who lobby the product team for one tiny customer-specific featurette

• Postponing work on improved automated test scripts (“just for this week”) while we finish urgent manual testing on a hot patch

• Pulling our one advanced researcher into a few design reviews for the core product

• Planning to visit the gym next Monday rather than today

All of these make sense in small quantities.  (BTW, if you haven’t read Daniel Kahneman’s Thinking, Fast and Slow, you’re missing a brilliant view of decision-making.) Try this experiment in the privacy of your office:


1. Look back at last quarter

Sort your completed user stories (or features or epics or work items) into these four buckets:

• Planned features. Customer visible improvements and new products that were on the immediate roadmap at the beginning of the quarter. Agile teams should include story/feature-level testing and whatever constitutes “DONE”.

• Unplanned features. Sales one-offs, unexpected customer commitments, executive additions and other work not on the roadmap at the beginning of the quarter. Mid-quarter surprises.

• Quality and development infrastructure. Test automation, refactoring, emergency bug fixes, DevOps, training and other work that isn’t directly visible to end customers. Waterfall teams should include QA/testing here.

• Longer-term research. Research, analysis and prototyping for things at least two quarters away. Figuring out how to solve hard problems for the future.

Sum up the story points “spent” (or whatever you measure instead) in each bucket, rounded to the nearest 5-10%. If you’re not sure which bucket something goes into, quickly pick one that seems right. This is directional, not precise.


2. Draw it as a pie chart

Executives and non-technical folks understand pie charts better than columns of numbers.  Your chart might look like something like this shown in the images. 



Image Image

3. Examine your implicit product budget

This is how you spent your immensely precious development budget. It’s your implicit product strategy: where recent choices have taken you.  Are you surprised?  What trade-offs or lifecycle stage does it suggest? How would your C-level executives react to this mix?


Notice that pie charts force us to look at proportions, not absolute numbers. As product managers or executives, we’re always looking to jam just one more thing into the development queue. But pie charts highlight (instead) relative spending by category.  If you could make 5% between slices next quarter, what would you move?


Typical reactions or observations:

• “We keep talking about investing in quality, automated testing and agile but keep pushing this back one quarter at a time as releases run late.”

• “Our sales team consistently captures 20-30% of the entire pie, which slips our major quarterly release. This might help our executives see how each little insertion adds up to real costs.”

• “We’re in a mature business and not spending much on long-term R&D. But our strategic plan says that we should be growing 2-3 entirely new businesses for next year. Mismatch!”

• “We’re built on very old platforms, which costs a lot in terms of maintenance/ infrastructure/old tools to keep things working. We might invest heavily for one quarter to upgrade parts of the architecture and then be able to shift resources back to features.”


4.  Make this a regular practice

Consider allocating a budget at the beginning of the quarter and tagging each story with its category. Then look at completed quarter-to-date points before each sprint planning session. Product managers/ owners and the overall team can rebalance along the way to reduce drift.


At the end of each quarter, discuss whether the mix is right. Should you shift towards (or away from) additional features next quarter? Do you need more review of sale’s requests to keep them from overwhelming planned work? Has your Q1 over-investment in quality tools pair off enough to move resources elsewhere?  This helps create product-level strategy, insulated from the latest disaster.



Your overall product spending defines a strategy, even if unintentionally. Apply some simple tools, and see what you discover.

For up to £250 Bonus for sports, use our exclusive bet365 Bonus www.abonuscode.co.uk Claim your bonus and start betting at bet365 now.
PM Essence
Three questions every program manager must ask 

                                                                                                                       - Tathagat Varma


Suppose you are the new program manager assigned to a program. How would you go about finding your way inside the complex maze of a program, its stakeholders, sponsors, component teams and various vendors? If the program is yet to commence, you might be able to get involved much more deeply and influence the state of affairs meaningfully. But if the program is already underway, what do you do?


If you take time and 'learn' about the program before you act, you might get a deep and thorough understanding of the program but then you might be under time-pressure to deliver results faster. On the other hand, if you straightaway jump into the mechanics of the program, sooner than you realize, you are neck-deep and drowning into the gooey tarpit of unending stream of fires. Yes, you might start delivering the goods that make your program sponsors happy (at least in the short term) but you might not be bringing about systemic change that make you strategic in thinking and approach. Without a more holistic and long-term thinking, you also start drinking from the same well and very soon, you are also just another 'manager' who is fighting fires rather than working proactively to prevent them in the first place. Mind you - if they wanted another firefighter (no offense to the selfless and noble profession of firefighting), they would have hired one! So, how do you make a mark?


Over time, I have found asking some simple questions is a great way to get started. Interestingly, these simple questions are very powerful and if the program team can't answer them unanimously, it is a pointer that something is not quite right.


Here we go:


What are the goals? If the goal is to put out a quick prototype that serves as a placeholder for conversation with customers (as opposed to a PowerPoint-laden marketing brochure that no one trusts anyway), then no point in having a complex program management mechanism in place. On the other hand, if the goal is to do something like build a skyscraper in two weeks then you will need a very rigorous program governance structure in place with months of advance planning, contracting, timelines, SLAs and so on. Not knowing the goals is like not knowing where's the finish line, or not having a clear picture of what the success will look like - we might keep pressing on but keep moving in circles, or might misdirect our efforts into something else that looks like success but is not! Kennedy's vision of sending a man to moon - and bringing him back alive - before the end of the decade is a great example of what is the goal - it fired up an entire nation and aligned everyone to that one single goal.


I once led a large program (over 190+ engineers in my team developing a complex 3G soft switch). It was an extremely important product for the company - perhaps the most critical endeavor that year, more so because in the previous year, we had blown away millions of R&D dollars building the product that never saw the light of the day and wastage of money apart, we lost one full year in the market. I recognized that the goals were very clear - deliver an architecturally sound product as soon as possible and ideally close the year with a field trial. I set up a rigorous program team in place that not only delivered the first version of product in 8 months flat, we did even better than the original goals - instead of closing the year with field trials, we actually closed it with an $18million sales of the product. On the other hand, a few years before in another company, while leading a product development in a very new area of Digital Video Broadcast, I took the risk-first approach and built an incremental development plan (think of the first increment as a simple yet technically complex "Hello World" displayed on your digital set-top box using the entire tech stack - hardware up - for the first time!) that helped us mitigate the technical risks and consolidate knowledge assets at each step rather than build it all in one shot. Even though the result was below par, any other approach wouldn't have made it any better!


Why are we doing it? Knowing the 'why' help us understand the desired end-state better, especially when the chips are down, a Program Manager will need to muster up all their energies and tactfulness to negotiate and broker agreements with various components teams (who, for all right reasons, might be more interested in their own line of sight rather than the overarching program goals - remember the agency theory?) or stakeholders in a politically-charged battlefield (e.g. CEO's pet project?). On a more positive note, this is also the articulation of the 'benefits' of a program and really distinguishes when a project ends ("outputs") and when a program delivers ("outcomes").


We have all heard of the story of the bricklayer, the mason and the cathedral builder. It is the deep understanding of the purpose that helps convert knowledge and skills into passion and an almost obsessions towards the end goal. When Tony Hseih says Zappos is not really into selling shoes online, but rather in the business of 'delivering happiness', it sets the context and direction for everyone in rank and file and aligns everyone's attitudes and behaviors towards the goal - even if sounds aspirational (and would you really want to pursue any goal that is not aspirational?). Not knowing 'why' behind something could be like being given the command to do something without knowing the context behind it, and people might go through the motions and do what is functionally expected of them but will never be deeply passionate about the cause that might make the difference in the bigger scheme of things. An interesting application of asking why 5 times makes sure that we don't get stuck at the superficial reasons but actually peel the layers and go to the deep cause underneath.


Where are the biggest pain points today? Are they inside the component teams, inside the program, or at the intersections? While a Program Management approach is a great way to address friction at the intersection, given that technically it is still an 'overhead' and hence it must be avoided when not required, it might not be the best approach to solve problems inside individual component teams. For example, if the product quality of a component is an issue, perhaps more of TDD or automation or CI or better code review practices might be needed in that team - rather than creating more checkpoints at the program level.


I recently bought a data card from a very reputed company. The product was absolutely lousy and the service was atrocious. Funny thing is they were too preoccupied in building marketing ads without paying any heed to customer's pain points. So much so, if you wrote your grievance on their Facebook page, they would delete it in no time, but they won't come and address your grievance. When we shut out ourselves from customer feedback, we lose sense of what's really making customer driving to us (or driving away from us, as in the example I gave earlier), and then we end up gold plating the requirements that we think the customers want. The end result is a train wreck in slow motion. When Flipkart realized that a major reason people don't buy online is because they don't want to pay upfront and then live in the anxiety of waiting for goods to be delivered or low credit card penetration, etc., they created Cash on Delivery, and when they realized they couldn't own the entire customer experience cycle without really making the last mile of buying cycle - the physical delivery of goods - a painless affair, they literally built their own courier workforce. Acquiring a deep understanding of these pain points will help you prioritize and focus on delivering them with alacrity.


I have found these three questions are not just relevant for a Program Manager but are helpful to just about anyone - a Product Manager trying to understand more about why customers buy (or ignore) their product, or an HR manager trying to create the new hiring campaign, and so on.

For up to £250 Bonus for sports, use our exclusive bet365 Bonus www.abonuscode.co.uk Claim your bonus and start betting at bet365 now.
PM Essence
Being Agile Vs Following Agile 

                                                                                                                       - Naveen Kumar Singh


I see some of the interesting discussion about agile especially by so called Agile Guardian and few examples are listed below:-

• How to estimate project in Agile way?

• How to do resource planning in Agile?

• We are following Agile Project Management but facing so and so problem and how to deal with those?

• Why Agile fails?

• What kind of project are more suitable for Agile?


So you are following Agile but you are not Agile that’s why you have these questions? Are you aware about agility or just heard about Agile? You really think that you can follow Agile or you are trying to micro-manage your project? How much you know about Project Management or your company/customer ask you to be Agile to deliver a piece of work in Agile way?


Be Agile if you’re looking for agility. Agile is a philosophy that built around people. Do you perceive people as resources or headcount? Then please change your perception. People are not equal to resources.


Any process that is based on Inspect and Adapt by people is Agile. Focus should be on meeting customer expectation not just following process. What is the use of process if that is not delivering business values?


Agile is a natural way of developing product. It’s not hard to learn but may be difficult to practice, especially when you think everyone should be Agile except you.



My Experience

I joined my 1st  company in 1997. At that time there was nobody in my company who knew about software and matter of fact that I bought 1st computer for my company and started writing software for financial accounting system. I knew nothing about accounts but was open to learn and automate it. Being an individual developer, tester and analyst I was supposed to learn, build and test a system that was completely new to me. I was successful because I was open to collaborate with business people to learn, build and demonstrate my work as frequently as possible. This helped me to learn financial accounting system and solve business problem..  I realised that I followed nothing but an agile process for being successful.


Take away

Be agile first before you follow agile. Open to understand business and then think about product. Product is not only about the thing that you touch and feel  but also about what services your product is delivering. System thinking is not a fancy thing but required to build a product that can solve your business problem.

For up to £250 Bonus for sports, use our exclusive bet365 Bonus www.abonuscode.co.uk Claim your bonus and start betting at bet365 now.
PM Essence
Lessons Learned in Project Management 
                                                                                            - Sunand Sharma, PMP 

In Project Management we rarely seem to apply ‘Lessons Learned’. Lessons learned (both good and bad) can possibly be the most powerful Project Management tool available. 


When and how to capture lessons learned

We should not wait until the end of a project to determine the Lessons Learned. The danger of parking the identify, capture and analyze phases of  lesson learned until the end of a project  is risky as  most project team members will already be focused on the next project by then. Project momentum would have been slowed down and most of the team members will see this as a 'box ticking' exercise. As a result, only a fraction of the lessons that could be valuable to future projects are recorded and passed on. Even if an organization has an effective method of communicating its lessons and learning from them, the most important element (identifying and capturing Lessons Learned) would have been compromised. 




Projects are generally split into a number of phases, milestones or gates and will overlap with other projects that are approaching the same phase in their project life cycle. Lessons Learned Reviews should be carried out at the end of each formal phase of the project and any learning’s should be rapidly utilized both within the project being reviewed and in other related projects. 


Setting up a Lessons Learned log during the project start-up will help to establish the process as a core part of Project Management. Encouraging its use and regularly reviewing it as part of the Risk Management process will also make it more meaningful and relevant to the work of the team. Ongoing capture of what was learned “as you go” will also make it a lot easier to incorporate Lessons Learned in the end of project report.


How and when to share lessons learned 

It is not enough to close out the project and to create a Lessons Learned report - the reports have to be made available to others in a way that makes them want to read and apply the lessons. The key to this is effective communication: 


• Organizing the critical information in an easy to understand way that makes its relevance apparent. 


• Ensuring that the different stakeholder groups are aware that the information is available and that they know where to find it. 


• Presenting the information in such a way that people can quickly extract it and turn it into useful actions.



Adoption – Issues, motivation and ways to gain adoption


A critical step for new projects is the review of relevant Lessons Learned.  In problem situations, the PM is very rarely challenged as to their awareness of whether a given problem had occurred on a similar project, whether it was foreseeable and to what extent had they taken measures to avoid its recurrence. Perhaps more focus on holding Project Managers to account in this way would result in adopting Lessons Learned processes more effectively. A potential issue for Lessons Learned is that there are “personalities” involved and/or an environment which is not conducive to working this way.


There is often a perception when a new project is set up – especially if preceding projects have been problematic - that a conscious effort should be made to wipe the slate clean. This usually means an entirely new team (immediate lack of continuity and no first-hand experience of what went before) with new opinions about what will work and what won’t. Too much reference to an earlier “unsuccessful” project is generally viewed as “not a good thing”, so even if a Lessons 


Learned report does exist it may never be looked at. In such situations it is little wonder that the same mistakes are made again, and even worse, mistakes are made on the new project in areas which were successful on the earlier project.


Making effective use of Lessons Learned is a cultural trait (e.g. to ‘sweep problems under the carpet’). However, the trigger to invest in ‘learning from mistakes’ (and successes) has to be based on individual experience. One that highlights the value gained from learning lessons. We remember to go and write Lessons Learned reports far more often than we go and look at someone else’s. Experience, being the tough teacher, means that there is a good chance you remember your own lessons so well, that you are tempted to not write them down, thinking by yourself – “nobody looks at them anyway do they?”

For up to £250 Bonus for sports, use our exclusive bet365 Bonus www.abonuscode.co.uk Claim your bonus and start betting at bet365 now.
PM Essence
Q. This technique is used typically in a process or product development/improvement process (such as DMAIC)  to understand a system and understand how one part effects the others. 

Future Reality trees are used to map out and understand a system and how one part effects the others. This is one of the thinking skills taught by Eliyahu Goldratt in his book "It's Not Luck". This Future Reality logic tree represents the desired reality to move to –how  the system should look like to operate as per the expectation. This tool helps to gain more insight into the system of causes and effects that must be created in order to create the desired reality. First the desired objectives at the top of a page are written the the injection(s) are written at the bottom of the page. Then the team  finds out if the injection that  have been identified can and will lead to the desired outcomes. Second, the team finds out more about what it will take to make the injection real. 
Reference [http://alberon.org/toc/futurerealitytree.php]
Share your Professional Achievements with us!
PM Accomplishments is YOUR section for sharing the joy of professional achievement with the rest of the community an inspiration for others to follow. Please share details of your achievement in not more than 50 words and send it along a high resolution picture associated with the accomplishment with the Chapter for publishing in PM Essence.
Certain rules apply:
♦The accomplishment must relate to project management profession. Please do not send information on promotions, new job, new role and other routine events
♦The accomplishment must be within the last 6 months
♦The entries received will be evaluated by the Chapter and selected accomplishment(s) will be published in the Essence of the following month.
Please write to This email address is being protected from spambots. You need JavaScript enabled to view it. and share details of your accomplishments and steal the limelight.
Project Management Practitioners' Conference 2016
PMI Bangalore India Chapter is proud to announce its 11th Annual Project Management Practitioners’ Conference (PMPC) in Bengaluru. The Conference will be held at the NIMHANS Convention Centre, from July 14-16, 2016.
The focus of the Conference will be "Enterprise Agility..." which resonates with the mood of the industry.
Agility is no more a virtue but a means of existence. In today's world the project managers have to deal with
extreme time pressures and the need to adapt to the market before other organizations could. The activities of
the entire organization focuses on gaining a small window of advantage over the competition to maintain market leadership.
This calls for,
• A Lean and Agile Organization
• Product and Service Strategies based on an understanding of the users
• Use of Technology to understand and reach out to the clients
• Adaptive workforce that keeps pace with the market
The Conference brings opportunities for everyone.
• Delegates soaking in the knowledge from others
• Speakers with a reach to an intellectual gathering of over 800
• Small Businesses who want to share the sparks that ignited them
• New opportunities for business houses
• Opportunities for participation to professional member organizations
Stay tuned for further communication from the Chapter or visit the Chapter website for further details about this Conference. Make sure that you free up your calendar to be part of this exciting event.
The Lighter Side of PM