Shifting the Culture of Project Management
April 8, 2008 at 10:00 am by ChrisIn previous posts, I've mentioned that there is a conflict of interest between the role of the deliverer and the resourcer. I pointed out that the deliverer's main concern is to deliver the project while fostering a good relationship with the client, while the resourcer's main concern is making sure that the company is properly utilized. This can make for an obvious tension between the deliverer's duties to their client and the company they represent. I've gone into detail before of how good resourcing will affect the deliverer, but in this post, I want to talk more about some specific strategies the deliver can employ to successfully shift the culture of from under-resourced-over-servicing to well-resourced servicing. 
First, let me clarify some terms. When I talk about the deliver role, I generally mean Project Manager (for a definition of the resourcing role, see here). While there are many definitions for project manager, the most appropriate definition for the role of Project Manager as we understand it within our staff at Newfangled can be found among those listed in Max's Project Management Glossary. According to Max, the project manager is:
"The person responsible for delivering the project in the agreed schedule, to the correct technical specification, i.e. defined to meet user requirements, and within the approved budget and other specified criteria, e.g. Key Performance Indicators. The project manager is the individual ultimately responsible to the end user."This means that our project managers need to be thoroughly knowledgeable about the scope, functionality, design, and development of the project in addition to being capable of managing client communication and the many deadlines within the overall schedule. Ultimately, this is a fusion of how the Account Manager and Project Manager roles are traditionally understood in an agency context, but incorporates some more technical aspects since what we deliver is both design and web development. However, most of the problems I encountered (or created) as a project manager were not the result of mis-communicating technical implementation issues, but the result of bad service and bad habits. Below is a simple David Baker scheme for shifting the over-servicing project management culture by employing some good service habits in coordination with resourcing: All Promises should be Delayed When on the phone with a client, there is a pretty good chance that, at some point in the conversation, you will be put on the spot with either a technical question beyond your expertise or with a request you cannot fully answer until it has been reviewed, priced and scheduled. In times past when I've run into trouble, I can often trace it back to this point because rather than delaying my response ("Let me get back to you..."), I've tried to answer immediately ("Well..."). In retrospect, it's easy to see how I was really shooting myself in the foot. Though one of your goals as the project manager is to maintain your authority over a project, not being able to answer a question right away does not necessarily hinder your control in this situation. In fact, rushing to answer a question and doing so incorrectly is more indicative of not being in control. In regard to technical questions, you should not expect yourself to have encyclopedic knowledge of all the various technical aspects or options of a project, so have no fear of being clear with your client that you need to look into the matter further and will get back to them shortly. If your research takes longer than you thought, take a moment to email or call them quickly just to check in and let them know that you're still working on getting the info you need to answer their question. Though your knowledge will increase with experience, as your client roster grows, you'll still need to do this as you discover the limits of your own memory- and that's ok. You're human, after all. Delaying promises is also a good response to requests. Every request for new work should be discussed and recorded in your initial conversation. This is a good opportunity for you to help the client to refine their ideas and perhaps consider factors they may not be aware of. However, the response they were probably looking for (i.e. When can it be done? and How Much?) should be delayed until it can be reviewed by your developers, then priced and scheduled by resourcing. Once you have a specific scope, price and time line planned out, you can respond to the client's request accurately. The client should see you as their point of contact with the rest of the company, not as a switch-thrower. All Promises should be Centralized In addition to needing to delay new work requests for the sake of clarifying the project manager's role, it's essential to do this in order to enable resourcing to do its job. When that request comes in, delaying it is step one, but identifying the delay ("Let me get back to you after I've reviewed this with Resourcing") will help your client to understand and respect how the company works. By delivering the price and schedule for work on behalf of the resourcer, rather than quoting it ad hoc, you will prevent the discussion from turning in to a bargaining situation or an apology for undelivered expectations and enable the resourcer to control the allocation of internal resources among multiple deliverers. All Promises should be Remote One of the other factors that often can cause trouble is your control (or lack thereof) of the boundary between you and your client. Because your promises should be centralized, as described above, a good response to a request made while you're on the road or meeting with a client in person should be that you will return to the office, review with resourcing, and then get back to the client. If being put on the spot is common and hard to resist over the phone, think how much more so it is in person or on your cellphone. Additionally, I would recommend giving consideration to clearly limiting the methods by which you are available to your client. For example, if you use an alias for your work email address and point it to your Gmail account, chances are that you've seen your clients' names appear in your chat list. Your best response is to block them immediately and let them know kindly that email and phone are your preferred contact methods. It's nothing personal, but IM chat is just too much. If you are prompt in responding to your client, limiting the method to your office phone and email should not be a problem at all. I've realized over the past few months that project management isn't something you can fully train for- the job really is the training. While there are, of course, some prerequisite skills, most of what you need to be successful will come over time as you get to know your clients and the resources you have available to you, and then review the mistakes you've made in order to build good habits to prevent making them again. As I've gotten to know and use the simple scheme above, I can clearly see how it would have prevented many of the rough spots I got myself into before. |
Tags: project-management resourcing
 |  |  |  |  |  |
