 Christopher Butler Strategy and Resourcing Hi, I'm Chris. I've been working at Newfangled since September, 2004. | Chris Butler's Blog |
 | Subscribe to this blog Click this link to view blog as XML. View a list of all Newfangled blogs >> Subscribe to all Newfangled blogs >> |  | Search Chris' blog |
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
 |  |  |  |  |  |
Timekeeping is at the Root of any Successful Resourcing System
March 19, 2008 at 4:00 pm by ChrisIn my last two posts about Resourcing, you might have noticed a recurring theme: data. Proper Resourcing just would not be possible without the availability of reliable and consistent data. In our case, we have two types of data that are necessary to make sense of where we stand at any point in time, time and pricing. 
Because we are a service company, our pricing is contingent upon the time we spend on projects. This means that our time data is central to our understanding of our utilization, and any improvements we could make to how we work. Each of our employees enters their time on a daily basis categorized by date, project type, project name, task description and time spent. We call this record a timesheet. We ensure that the categories directly relate to billing phases and terms so that when we evaluate the data it can be understood in terms of the financial picture as well as the schedule. After all, time is money, right? Once we had a large enough sample of data, we were able to look at it in order to evaluate our utilization picture. Overall, we can assess our utilization by looking at the total number of hours our employees will work in a particular time period. For example, in a company of 15 full-time employees (close to our size), the total work hours per week would be roughly 560 hours (7.5 hours x 5 days x 15 employees = 562.5 hours/week). This number of hours in a typical work year would amount to about 26,000 hours a year (562.5 hours/week X 47 weeks = 26,437.5 hours/year). If we were to bill at 100% utilization, we would capture our full hourly rate multiplied by that total number of hours and the result would be equivalent to our gross income. However, 100% utilization is not realistic. Some employees' time is going to be more billable than others, and some time spent in any given project will not be billable if initial pricing was inaccurate. A more likely goal would be 60%. With a goal like 60%, a more realistic amount of billable hours would be around 15,600. In any case, according to David Baker, if Resourcing is being done properly with good time data at its disposal, utilization could be expected to improve by 1.5% a month. In the same manner, individual projects can be evaluated in terms of meeting or exceeding budgets using our time data. We typically assemble budgets based upon the various roles taken by employees within the different phases of a project. Each role in each phase will have a budget value. While we usually don't itemize these budgets in our proposals, we keep the itemization internally so that we can match time data with it in order to track projects as they are happening or determine exactly where a budget was or was not accurate later on. Because we record detailed descriptions with every time entry, we can even get a sense for why something went wrong if it isn't immediately obvious (for example, seeing a developer log like "data import took longer than expected due to corruption and mismatches") or recognize patterns and account for them in future schedule or budget planning. Having a realistic picture of utilization allows us to be able to determine time standards for certain types of tasks, which in turn helps us to establish good pricing for projects. As we increase in efficiency, time spent in implementation should decrease (if our utilization is not great) or level out (due to lack of standardization) allowing for a reasonable profit margin. We can also plan project timelines in advance and more reliably by knowing how long comparable tasks took given comparable circumstances. This is all based upon having a large pool of data and having taken the time to measure utilization, diagnose the areas where we over-service and/or under-price, and made adjustments incrementally. As you can see, timekeeping is essential to any method of achieving optimal utilization! |
Tags: project-management resourcing
| | | | | |
Why Delivering and Resourcing Cannot be Shared Responsibilities
March 13, 2008 at 12:00 pm by ChrisIt used to be the case that our Project Managers would schedule and price work for existing clients as it came in. Naturally, this resulted in frequent 'traffic' meetings during which we would have to determine as a group how to sort tasks by priority after they had already been priced and promised to our clients. Clearly we had this backward. As I mentioned in my last post, this made the Summer of 2007 a tough time for everyone- something we could have prevented by doing Resourcing properly. 
Prior to actually setting up a Resourcing procedure, all we were really doing was just trying to get good work out the door quickly and keep our clients happy. Unfortunately, the way we went about doing that was causing our utilization to be very low. We were spending a disproportionate amount of time to that which we were billing for, and resources were going on a first-come-first-serve basis, often being depended upon in excess of capability. We created a bottleneck at our development level because our programmers would be at the mercy of their task lists, and to their credit, would try valiantly to meet the deadlines no matter how unrealistic they may have been. This made for delays and reduced quality, which meant we were not succeeding at what we were trying to do- keeping our clients happy. As the Recourses seminar attendee said, "they'll never remember that you did it fast," but they will remember that you did it poorly. Why wasn't our ad hoc "resourcing" scheme not working? Ultimately, it is because there is a conflict of interest between the role of the Deliverer and the Resourcer. The Deliverer's main concern is to deliver the project in the agreed schedule, to the correct technical specification, within the approved budget, while fostering a good relationship with the client. (In our environment, we fuse project and client management into one uber mastermind position ;-) This can make for an obvious tension when it seems like the client's satisfaction can only come at the expense of over servicing or under charging, though ultimately the Deliverer's responsibility is to the company's interests. On the other hand, the Resourcer's main concern is making sure that the company is properly utilized. If Resourcing is being done well, then the Deliverer should be set up for success and not have to worry about haggling over quotes, bending time to conform to an unreasonable schedule, or committing more development resources than are available. All of the pricing, scheduling and allocation of resources should be determined based upon the big picture of our production schedule and utilization so that what we have to offer our clients is actually what we have to offer. If we can be clear and efficient in Resourcing, our Project Managers can always be one step ahead and deliver well. In my next post, I'll talk about why timekeeping is the key to successful Resourcing. |
Tags: project-management resourcing
| | | | | |
Introducing Resourcing
March 11, 2008 at 2:30 pm by Chris| A Little Background 2007 was a busy year at Newfangled. So busy, in fact, that it put to the test just about every aspect of our operation. Our positioning, our process, our team's role breakdown, our scheduling, and our pricing were all examined closely (see Mark's blog on our new Project Anatomy). Needless to say, we made it through and learned quite a bit about how we can improve and be an even better company than we were before. Instrumental in this process was the consulting we received from David Baker, owner of ReCourses, Inc. David is an expert in consulting companies like ours and helping them to solidify positioning, management, and process. One of his recommendations was to introduce a new role to our team: Resourcing. I've taken on that role (in addition to Strategy, something I'll probably talk more about at some point), while Katie Jamison has done a great job already of taking over as Project Manager for my clients. 
Resourcing and Measuring UtilizationThe primary goal of Resourcing is to ensure that your company is properly utilized. Utilization, according to Max's Project Management Glossary, is the "extent to which something is turned to practical use or account." I like David Baker's definition better, which is essentially that a company's utilization is the percentage of possible billable hours actually billed as reflected in your revenue. Given that definition, many professional services companies, especially creative agencies, may quickly and rightly suspect that their utilization is low. Depending upon the number of employees that you consider primarily overhead, a reasonable utilization goal could be anywhere from 55 to 70%. Once you have measured your company's utilization, you can set a goal for improvement. It might be easy to jump to the conclusion that the way to achieve your goal is to simply raise your rates. However, David challenged us to really evaluate why our utilization was low. Was it due to under charging, or was it due to over servicing? As it turns out, it's actually a subtle combination of the two, but what was important was acknowledging that over servicing was even possible! We even determined later that, contrary to most agencies, we weren't struggling with staying within implementation budgets but were not accounting for the time spent actually managing the project. For a typical project, we've found that Strategy, Project Management, QA, and Support actually account for over 50% of the total time spent, with the remaining 50% to be divided among implementation of Prototyping, Design and Development. That means that a major amount of work, and a significant value, resides with the way things are delivered, not just the implementation. As you might imagine, getting these budget ratios wrong will significantly affect your utilization. Adjusting how you plan your production schedule is another way to improve utilization. When we were at our busiest in 2007, it was mostly due to a major traffic jam in our schedule- one we could have prevented. Since our schedule is divided between two different kinds of work - new projects and upgrades to existing client sites - it's difficult to predict when things are going to be tight. We can plan out new projects, but we never know when an existing client might call. This has historically caused us to attempt to schedule more work in a week than there are hours to work! This kind of scheduling is partly due to the fear that not being able to give immediate service is somehow a bad thing. However, we've realized that doing a subpar job quickly is far worse than doing a great job slowly. As one participant in a recent ReCourses seminar rightly put it, "they'll never remember that you did it fast." She is completely right. What they will remember are all the mistakes made trying to rush a project through. The fact is that we are in demand- so much so that we now are scheduled out months in advance- and we're not willing to rush projects at the expense of quality. Sure, some projects have to wait to get started, but we believe they are worth waiting for. The Nitty Gritty A lot of things need to be in place in order to evaluate and maintain proper utilization. First, there needs to be as much data on hand as possible to ensure that Resourcing is not a wasted effort. We get this data from our timekeeping system being integrated with our project management, scheduling and billing tools. With this data on hand, Resourcing can evaluate profitability for completed projects and determine pricing for future projects, recommend realistic workloads for the development staff, monitor quality, anticipate over and under-utilization due to various factors, maintain timesheet and project management systems, etc. Yes, there is much to do! This is why Resourcing needed to be a new role for us, not just something else that existing delivering staff does in addition to everything else they already do. In my next post, I'll talk more about why Delivering (account management, or as we call it, project management) and Resourcing cannot be shared by the same team members. |
Tags: project-management resourcing
| | | | | |
RSS