As a program manager, you need to make an honest assessment of the credibility of the plan to deliver the program immediately upon being assigned.  By plan, I mean the sum total of the timing, cost estimates, forecasted margin, quality expectations, customer satisfaction, and so on.  Simply accepting what you have been given, including the assumptions of success with the parameters that exist at the beginning, can lead to a gap between the expected and actual delivery. 

In a highly competitive environment, Sales teams and Advanced Engineering (or “Phase 0”, if you prefer) are often forced to rely on rose-colored-glasses to achieve their objectives.  Even if your organization claims that they will be held accountable for over-selling, you and your cross-functional team will be blamed for under-delivering if the stakeholders expectations were set unreasonably high at the start of the program.  Programs that are months or years long are perfect breeding grounds for industrial amnesia.

Your Sales team is receiving pressure to reduce the price prior to award of contract.  So, Engineering is tasked to reduce the time it will take to deliver the project and the cost of the bill of materials.  They conspire to “hit a number” by making assumptions about eliminating entire parts off the bill of materials or a “booking” a miracle that they need Purchasing to pull off when awarding components that will be bought instead of made.  Advanced Engineering is usually made up of intelligent dreamers that don’t have to work with manufacturing to ensure that a product can be built as it is imagined and they don’t have to deliver products to customers.  In short, the recipe for Sales and Advanced Engineering success is the perfect storm of a challenge for the cross-functional team in charge of execution.

This isn’t a blame game.  Inexperienced program managers can clearly be the root cause for cost overruns, late delivery and missed expectations.  So, too, can the inexperienced or dubious Sales and Advanced Engineering teams be the root cause for a project being set up to fail.  Sales and Advanced Engineering succeed by raising expectations.  Experienced program managers succeed by lowering expectations so the team can exceed them.  The constructive tension that the difference creates must be understood and managed by the program manager.

So, it is advisable to perform your own assessment of the credibility of the plan and expected results at the earliest possible time.  It won’t change what you are up against and it is likely too late to make any changes in scope that target reality.  However, it prevents everybody wondering why the program looked so much more difficult to execute than was forecast or why the margin was so far off from when the business was awarded.

I’ve read many postings online about all of the subject matter to be learned about the discipline of Program Management.  I’ve also known some people that knew an intimidating amount of Program Management jargon that, no doubt, came from serious studying about Program Management.  My experience, however, has been, that these people can be a source of power in a discussion about the topic of Program Management but they lack the practical skills to relate to a cross-functional team and launch a program successfully.

These people can create forms that nobody can understand and create timelines that are so complicated that nobody can follow.  Then I’ve seen them stare down their noses at the people that are really doing the work as if to say, “What’s not to understand?  I’m from Corporate, and I’m here to help.  You’re not as smart as I thought you were.” 

For my whole career in Program Management, I have said, “Program Managers neither create nor destroy information.  They merely orchestrate the cross functional resources to deliver on the contractual obligations of the enterprise.” 

Let’s face it, the Program Manager’s only marketable output is Program Management.  There is no product we can put a price tag on and sell.  We have to guide the team, anticipate risk, mitigate risk, balance resources, and on and on.  If people-skills is one of the most important factors in Program Management, and I believe it is, they why do Program Managers attempt to dilute the functional team members workload with a bunch of self-serving Program Management jargon?

Cross-functional team members just want to be led.  They want somebody to keep the end goal in front of them and have meaningful touch-points for assessing project status and direction.  They do not want to learn how many fancy Program Management concepts you can articulate.

I get that this “expertise” must exist.  It has its place in the Program Management Office (PMO).  The PMO is the place where the Program Managers go to sharpen their saw and make sure they have the right tools in the toolbox.  However, I believe that when a PM is deployed by the PMO, they need to spend less time talking about the tools and more time demonstrating what the tools can produce.  

If the carpenter you hired to build your deck spent all of his time trying to impress you with his special saw instead of using it to build your deck, would you think he was helpful?  The tool is of no value other than the product that it produces.

When starting a project turnaround, you have to start by learning the scope of the project and developing a new plan to accomplish the goals of the project.  Attempting to bridge to a broken plan can become a project of its own.  It doesn’t add value to executing the turnaround and it actually dilutes valuable resources and consumes their bandwidth that could otherwise be used to execute the turnaround plan.

You have to convert to the new plan and not look back.  That might be difficult for some team members.  After buying into a plan for a period of time, it’s difficult to imagine the best solution is to roll a grenade into the room and start over. 

The same approach applies to organizational turnarounds.  After the discovery phase (interviewing everybody in the company to learn how things are done), you set the goals and then relentlessly execute the plan to accomplish them.  It starts off messy, like cleaning out your garage.  You start by taking everything out of the garage.  If someone passes judgment at that moment, they might conclude that you’ve made a bigger mess.  However, you have to stop doing what you were doing and start something new.  You can’t steal second base until you’ve taken your foot off of first.

One of the biggest opportunities for a Program Manager to exhibit leadership is during, what PMBOK refers to as, the “controlling processes”.  This is the part of PMBOK and PMP training that says that project performance must be monitored to identify variances from the original plan.  The idea being that the Program Manager can refine the plan to compensate for negative variances.

I believe, taken literally, this approach means the Program Manager has failed at leadership.  It’s letting the project happen to the Program Manager, rather than driving results.  It presumes that being late can only be seen in hindsight and not predicted by closely monitoring progress instead of functional group results.  Functional group output should be viewed as that functional group’s mini-launch.  It’s what they owe the cross-functional team.  The entire team is not allowed to miss launch, so functional teams should not be allowed to miss their mini-launches.

As an example of how a Program Manager can provide leadership, consider a product engineering team that is developing components that must be purchased and assembled.  If the development process takes 12 weeks, Purchasing should expect to receive data and drawings 12 weeks after Engineering starts working on designs.

However, if Purchasing waits until the 12 weeks is expired to being the sourcing process, they will have to get up to speed before they know the types of products that have to be bought and learn about any special requirements before they can contact suppliers.  Likewise, the suppliers will have a steep learning curve.  It’s like a relay race where runner 2 is standing still and runner 1 crashes into runner 2 to hand off the baton.  In real relay races, runner 2 starts jogging to get up to speed in anticipation of runner 1 arriving.  So, in our example, Purchasing can be brought into project team meetings 4 to 6 weeks before the final design is complete.  They can learn that the product is bigger than a breadbox and smaller than an elephant.  They can start to consider which commodities they need to buy and preferred suppliers.  They can even share drawings with suppliers to get preliminary estimates and feasibility consideration. 

That’s leadership.  It creates a pull on engineering and creates constructive pressure to not be late.  It pulls Purchasing into the project and takes away excuses for being late or getting a slow start.  It allows Purchasing and suppliers to have a say in the design before it is released.  It puts the emphasis on the success of the project instead of allowing different functional groups to sub-optimize their output over that of the entire project.

This is an example of where I believe having a system (PMBOK) gives Program Managers false confidence that they can turn off their brains because a system or process will deliver the project.  It creates “newspaper reporter” Program Managers instead of “air traffic controller” Program Managers.  The team desperately wants to be led.  They probably feel that they already have enough managers.  

Email – A Necessary Evil           

There is no doubt that email has many positive attributes when used appropriately.  It speeds communication.  It invites or informs many people simultaneously.  It saves money on postage.  However, overall project or team efficiency can be negatively affected by the misuse of email.

Circumstances might not allow for a face-to-face discussion with our global interactions these days, and the matter might be too pressing to take the time to pen a note.  If that’s the case, I recommend taking the time to pick up the phone, if time zones allow, rather than (or in addition to) sending an email.

Deliver Bad News

It’s easier to deliver bad news related to project status if you don’t have to look the person to whom you are delivering it in the eye to see their disappointment and, maybe, to help suggest corrective actions.  The truth of the matter is that you were likely hired into your Corporate America job to be part of solutions rather than simply forwarding notifications.

As a Program Manager of a project with an estimated annual revenue of $500 million, I received an email from a teammate that said something like “…and if you don’t do x, y and z within the next 3 days, your project will be delayed by…”.  First of all, was it only MY project?  Was she not on the same team as me?  Secondly, if $500 million in revenue isn’t compulsion enough to get a project launched on time, what is?  I would have expected her to immediately approach me so we could address the situation together.

Impersonal

Remember the feeling you used to get when you read a handwritten letter?  It took somebody the effort of actually writing and somehow their personality was evident in the lettering or ink color selection.  They usually cared about their spelling and grammar and took care in the creation of the letter.  It’s a far cry from receiving an email full of half sentences and misspellings with poor punctuation and realizing that you are part of somebody’s attempt to multitask today.

Interaction used to force people that were uncomfortable in social situations to stretch to be contributors on a team.  Today, they hide behind their computer screens, happy to not interact.  The relief they feel from the interaction avoidance is outweighed by the loss of the benefits that such interaction affords.  When challenging situations occur, teams often succeed and fail by the nuances of how well they know each other and how they can count on each other.  You don’t get to know each other at the same depth if you only communicate through email.

Misunderstanding

Tones and inflections are non-existent in email.  Often, attempts to introduce tones and inflections by using sarcastic wording can be misinterpreted and lead to misunderstanding and conflict.  Something that might come across as a humorous one-liner in a face-to-face conversation can be perceived as insensitive or insulting in email. 

Overload

I don’t know about you, but I receive many emails on any given day.  For many of them, they contain a message that is substantive enough that if it were a phone call, and if I rated it a high enough priority, I would spend an hour or a day processing the details for the progression of the project that I was working on.  It’s a cop out for the sending to just throw it over the wall and leave it to the reader to figure out how important it is and how to fit it into his or her day.

Sure, the sender gets to feel like they “took action on” or “processed” a hundred different items that day.  However, most people are employed to advance the project to which they are assigned, not to clear out their inbox.  Most of the time, crossing something off your task list means the task doesn’t need to be done anymore, the question has been answered or the problem has been solved. 

Simply speed-reading and then forwarding something doesn’t cut it.  Before email, those types of assignments used to be gathered on an agenda and then team members would assemble in a conference room for organic interaction of carbon-based life forms (people would actually talk to each other).  We called them meetings.  Some things would be solved.  Some questions would be answered.  Some assignments would be given and, most importantly, accepted with agreement on prioritization.

Closing

For all of its benefits, email is just another tool in the toolbox and our ability to select the best tool for the particular task will still be judged by those around us.  So, before you fire off the next email that is either so sloppy that people wonder what you mean or so long that nobody has time to read it, consider whether a phone call or a note would be the better tool selection.

Program managers: We know a good one when we see one and the difference is almost always in the intangibles.  The administrated reports, timelines and budgets are the easy part.  It's also the only thing that people "see" from program managers.  So, the program manager’s value can be underestimated.  It's managing the space between functional group tasks that gets the job done, gets the program delivered and gets the parts on the floor. 

Like a choreographer or a symphony conductor, program managers set the rhythm or orchestrate the resources to deliver on the contractual obligations of the enterprise.

Credibility – Without it, Program Managers are sunk.

As a Program Manager, you are constantly being watched by your team.  They are looking to see if you know how to make a decision, if you have character and if you know how to prioritize.  They want to know if you are logical and if your actions match your words.

These people want to be led.  As Engineers, Designers, members of Purchasing, Operations staff, Sales, Quality Engineers, they are prepared to bring excellence and sweat to the cross functional team, but they want to know if you know how to orchestrate the team to deliver on the obligations of the enterprise.

The inexperienced Program Managers that I have had working for me in the past try to establish their credibility with politics or frequent lessons on PMBOK or other Program Management tools.  The team quickly learns that there are no Program Management tools for any problem they are experiencing.  All the team hears is: “Ready, FIRE!, aim”.  What the team needs is the Program Manager’s most important tool:  leadership.  The successful Program Managers allow processes to take a backseat to problem solving and solutions. 

When the team see’s the Program Manager accept blame for the team and not single out an individual, the Program Manager earns credibility (of course, someone that just can’t get the job done needs to be dealt with, but I’m talking about the “nobody gets killed for a mistake” approach to leadership). 

Also, when the Program Manager protects the team from unreasonable customers, they earn credibility.  When the customer insists on a solution but the Program Manager explains that the team must analyze and decide before it can implement, the Program Manager gains credibility.  When the Program Manager leads with uncompromising integrity and character, the team will trust their leader based on credibility.

Programs are not long enough to lose credibility and regain it.  So, protect this valued resource at all times.

Ready, aim, FIRE!