The Skeptic’s Guide to Project Management, Part I: What Project Managers Actually Do
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Project Management. It's one of those jobs that, like helpdesk or technical writing, seems to go without explanation.
It's about managing projects. Duh.
A common assumption is that project management is obvious. Gather the requirements, get the estimates, build a plan, work the plan, and you are done.
If you want that article, no worries, there are plenty of books to choose from.
This not that article.
Instead of talking about what project managers should do, I will talk about what the successful ones actually do, and the practical and ethical consequences of that difference.
In this series, I will start with outlining general expectations for project managers (what you have to do to succeed right now), moving slowly toward how to reframe the work to create a more happy, healthy, productive work environment. And I'll do it with a skeptic's eye for detail, asking for evidence and alternative explanations, and allowing for the possibility that different people can do things in a different way.
Let's talk about what project managers actually do.
Why We Need Project Managers
Picture the organizational structure of your typical corporation. Below the business units you tend to see some sort of functional organization--IT over here, finance there, operations in a third place, marketing, sales, perhaps a legal department. Each of those big buckets likely has sub-buckets. IT might be split into operations and development, for example, and within IT Development you might have the web programmers, the testers, the analysts, the database programmers, and so on.
Whew.
The problem with functional organizations is that they can't get anything done.
Oh, sure, each individual specialty can do its part. Purchasing can approve expense reimbursements and programmers can write code, but try getting all the specialties to work together to actually build a product. Each team will want to receive work in a format that is easy for them to process, and produce work in an output that is convenient. This optimization of each part, not the whole, creates friction between the teams. Professor and consultant John Seddon calls this friction “failure demand”, meaning that the output of process is not fit for use, and the customer has to make the request a second or third time, creating new demand on the system.
Now think of the company that has dozens of projects, hundreds of tasks and assignments and pieces of work, all done by mere humans who make mistakes and use different words to mean the same thing.
It is exactly because of this complexity, these conflicts of interest and these cross-cutting concerns that we need project managers. The entire job was created to solve this problem of coordinating across teams.
If you can agree with me that these barriers are real, I hope you can also see that they are something to be ignored, but tall obstacles to be dealt with. Let’s talk about how to overcome them.
How Project Managers Work
In some cases, a project manager may have input into the annual review process, but in general they have no formal authority. The project manager may be able to get a piece of paper that says the project has some percentage of a programmer’s time, but no piece of paper can guarantee time, attention, or energy. For example, the project manager may be trying to accomplish the project, while the line manager may have business goals to improve process, get his people to training, or decrease the average time from request-to-fix of a support ticket. If those goals are not aligned, the different people in the system will be trying to accomplish different things with limited resources -- a prescription for competition. Ram Khanal put the issue this way, in his paper on internal competition: “When People are concerned primarily about their relative ranking, there are incentives for them to avoid helping their peers to improve their performance and, at worst, to undermine or sabotage their peers' performance.” (See http://www.scribd.com/doc/50718200/Concept-of-internal-competition-in-an-organizational-behavior.)
Again, we need project managers to get things done, but conflicts can also arise in the work itself. "The server isn't ready," the staff will say, or "The database is the wrong version." Perhaps there is some sort of production emergency, or coding is just taking longer than expected. Remember those teams interfacing in incompatible ways? It shows up here, and it’s going to be hard to overcome.
Now the project manager has got a problem: the executives want the project yesterday, the schedule says it's got to be done on the first of June, and the technical staff says they can't have it done until August.
The Big Secret
On one hand You have got conflict among teams, each trying to optimize for its own performance. On the other, you likely have more than one project stakeholder or sponsor -- each with their own goals and objectives, which many not be aligned. As the old saying goes, it is unlikely that you will be able to please all the people all of the time.
To be successful you’ll have to negotiate.which is the big secret.
Getting a reasonable schedule in the first place? Negotiation.
Winning the support of the technical team? Negotiation.
Getting people to see past the policies that don't make sense in this instance, to make an exception? Negotiation.
Creating a sense of buy-in from the technical team, so they "own" the dates and deliverable? Negotiation.
Last for this list but certainly not finally, working with the executives to create a reasonable schedule based on data, not wishful thinking? You guessed it. Negotiation.
Project Managers don't succeed by making ship dates. They succeed by building relationships, setting expectations, and inspiring and negotiating to get results.
To be effective, you'll need some influence. Let’s talk about the traits you can have to attract and build that influence.
On Leadership: Tips and Skills
Like the Dark Side in Star Wars, there are a host of techniques you might apply that offer a quick and easy way. These include intimidation, leadership by information control, fear and pressure.
Instead of those, I'm going to talk about leadership and legitimate influence, and some ways to get it.
Make Project Priorities Clear Let’s be fair. It can be hard for people to understand priorities when they swim in a sea of tasks and emails. So your project might be the number one priority of the business, but does that staff know that?
If your project is the number one priority, you can ask for the help of line leadership to make that clear. They can do this through emails, statements at department meetings, inviting you to an all-staff to explain the critical path, or just giving your project a little bit more time and attention. (People will notice what the big boss notices.)
When you ask for this, be very specific. You do not want your project as the third bullet-point in a ten-point list. You do not want it mentioned in passing for a few seconds during a rambling conversation. Instead, you want it as the only bullet point of the only slide.
It’s possible you don’t get this kind of support, and that’s fine. It’s possible your project really is priority number forty-five of fifty. In that case, it’s important to manage expectations, as priority forty-five will have its resources cut if other priorities are in danger. Make it clear: That is not project failure, that is the organization making tough choices.
Use Technical Credibility. On another project, a team lead told me he needed a "few weeks" to make a change. I opened up the version control system, downloaded the code, and made the change that afternoon.
Now I'm not particularly proud of that moment; I insulted the other team and fell into the trap of doing all the work myself. Still, I made the point that I understood the work and would not be sandbagged, and demonstrated that point. Other ways to build credibility include diving in and making contributions, from analysis to design, testing and coding. If you give the problem of the work itself some deep thoughts, find shortcuts, and communicate them to the technical team, suddenly you become a member of the team, not an outside taskmaster. That can make all the difference.
Master the Process. Project Managers can also accrue other skills, like filling out reimbursement forms and purchase orders. These tasks can be slow, awkward, and painful to others, and understanding the system can give you a sort of influence. By understanding the bureaucracy, you can cut through the red tape and get things done that other people cannot; you can also help others with your skills. With enough bureaucratic know-how you can do little gestures like buy lunch for the team, take care of niggling paperwork so they can focus on the project, or route the request properly through the architecture committee.
Find the Willing. So you can't get the data modeling team to work on your two-hour project; they need to work through six weeks of "tickets" that have priority over your project. Okay. That is the official system. But if it's really just two hours of work, maybe someone on that team, perhaps a friend of yours, might just do it on his lunch hour. If you start to hold your team meetings around lunch time, who knows; he might just start showing up to those as well. The point here is that if the official system is failing, feel free to work with, and work to grow, the team you actually have, not the team you should have.
Become a Connector. Most projects run into some problem: The database is not compatible with the webserver or the ERP upgrade changes the table structure of certain code, requiring a re-write. Whatever the reason, eventually your project will be blocked, and no single person will have all the answers. Connectors are people who don't have answers, but they know who to ask. Perhaps Rob Cross put this best in this 2002 article for the Harvard Business Review: “Managers invariably use their personal contacts when they need to, say, meet an impossible deadline, get advice on a strategic decision, or learn the truth about a new boss. Increasingly, it’s through these informal networks—not just through traditional organizational hierarchies—that information is found and work gets done.” Interestingly enough, the title of that article is “The people who make organizations go -- or stop.”
Use Humor. Sometimes the official position people take becomes absurd simply because to change the policy that late in the game would cause them to lose face. One way to get things done here is to "jiggle" the person with humor, that kindly points out the absurdity of the situation without causing a loss of face. On one project, urged to do more with less, I told the story of how my father used to joke with cashiers at the grocery store about the price, and how, when I turned sixteen, I tried the same thing. They only problem was that my sarcasm was poor, and the cashier took me seriously, offering that, if I really wanted to cut costs, I could take something out the bag ... or shop somewhere else. The group laughed out loud at the embarrassing story, but the point that there is no free lunch -- that also came in loud and clear.
Another time to use humor is when you are subtly being insulted; use it to change the subject instead of escalating the problem. In another meeting, after a particularly uncalled for verbal barrage, I responded, “Your fly is open.” It lightened the moment.
Allow Choice. In “Drive: The Surprising Truth About What Motivates Us”, author Daniel Pink places high emphasis on Meaning, Autonomy and Mastery. In other words, when people are given a responsible task and the room to do it as they see fit, performance improves. With technical people, you can do this by focusing the what -- the interface between systems, for instance -- and letting them decide how. If the how is written down in a methodology book, offer them other choices, like where to do the work, when to do the work (come in early, stay late), or when and how to structure the team meetings. If you have to, get them to suggest where to go for lunch, or if you should meet outside in the summer. When people start deciding for themselves, they can take ownership for their work and take responsibility for it. (We’ll come back to this later in this series.)
Get Charisma. Some people seem to carry a power within themselves; they can walk into a room and own the room. These folks can make you laugh, they can make you feel special -- you want to help them accomplish the mission. They'll be successful at whatever they do, be it real estate sales, new car sales, management or technical work. People want to believe in them. They can also make very good project managers. Charisma can be especially important when you are dealing with impossible situations; explaining to the executives that no, we can't go to the moon in six months with an operating budget of two million dollars. (People with Charisma don't say no; they lay out the situation, let the boss come to that conclusion, then nod along and agree "gosh, if you say so, I guess we can reel scope in a bit ...")
Popular culture claims that leaders are 'born', but the reality is influence can be cultivated. Even charisma is a skill that you can practice and improve upon. And humor? Most major cities have improvisational humor night classes and bootcamps designed to teach you to respond in the moment to challenging circumstances.
Putting it All Together
There's plenty of information out there are managing the work, building a plan, creating status reports and so on.
The skeptic’s guide is about the elephant in the room.
The first elephant in the room is about negotiation, a critical skill for success as a project manager. To negotiate well, you'll need influence, which I talked about above.
Once you have that influence, you’ll still want to negotiate well -- which we’ll talk about in the next article.
What would you like to hear? Email your feedback to matt.heusser@gmail.com.