Three Questions Every Program Manager Must Ask
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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 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 core 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. OTOH, if the goal is to do something like build a skyscraper in two weeks (like this http://www.cnet.com/news/chinese-build-skyscraper-in-just-15-days/), 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 on a large program (over 190+ engineers in my team developing a complex 3G softswitch). 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 the 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 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’ helps 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) 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 as 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’, 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 write your grievance on their facebook page, they will delete it 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 goldplating 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 that these are not just relevant for a program manager but are helpful to anyone – a product manager trying to understand more about why his customers buy (or ignore) their product, or an HR manager trying to create the new hiring campaign, and so on.