As a program manager I have to deal with many different specialists: marketers, lawyers, system architects, software developers, product managers etc. I come from a technical background so this really helps when dealing with software specialists as I find it easier to engage in discussion with them about technical ideas and issues. I guess you could say that this is one of my strengths.
Whilst on a business trip last year I met another program manager whose previous career was as a lawyer. His strength was that his legal background enabled him to easily divorce emotion from lines of argument, allowing him to clearly see how to steer a program when debate and emotions are running high.
Clearly his strength from previously being a lawyer and my strength on the technical side are different, yet we are both competent program managers. Nobody can have a detailed understanding of all the different types of specialists they will have to manage as a program manager, so I believe one of the key attributes of a program manager is knowing how to handle specialists. The fact that as a program manager you have to manage people specialising in areas in which you have no background is one of the things I believe makes program management more like General Management than Project Management.
If you are not a lawyer, then when you think about what a lawyer needs to do to get their job done you may not know where to start. You may feel equally confused when you think about what a doctor has to do to get their part of the program complete. However, there is one simple fact I use to remind me how to handle and manage these people, and that is: whatever job someone does, and no matter how complex, a series of steps (sequence of events) must be undertaken to complete it. Additionally, as the program manager you have the right to understand this sequence of events if not the technicalities of how something gets done.
Armed with this knowledge it’s possible to see how by asking some simple questions you can very quickly build up a picture of what needs to happen within streams you know nothing about. Here are some of the questions you might want to ask:
- What happens next?
- Can you explain that to me in language a 10 year old could understand?
- Who is doing that?
- Why does it take that long?
- Is there a simpler way, or is there anything which can be done to speed that up?
- What am I expected to do?
- What needs to happen before that can start?
Don’t be afraid to go through several iterations of asking these questions until you have a clear picture of who is doing what and when, along with what the risks and issues are. At the end of this exercise you will have a plan for this particular specialist area. At this point it’s a good idea walk through the plan with the specialist to validate it, and to place milestones into the plan so it’s easier for you to see if the plan is tracking as it should.
Let’s look at an example of inserting milestones to make this clearer. Suppose you are the program manager for a program which is to deliver a new type of home entertainment system to the market. A lawyer may have to do a number of things before it is sensible to start any R&D. This might include checking the IPR landscape is clear. Ensuring any open source software to be used is legally acceptable and consistent with the company’s strategy. Checking that there are no items within consumer law which conflict with what we want to do, amongst others. At this point in the plan we might insert a milestone called “Legal Groundwork Done”. Of course, after this point there are lots of other things the lawyer will have to do, but the point I’m trying to emphasise is that by using this milestone it makes it very easy to track if the legal groundwork has been done and we are all clear to start R&D. Of course, if the legal groundwork is not complete then it should be very clear that if we start R&D then we are doing so “at risk”.