 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 |
5 Simple Ways to Send Better Emails
May 1, 2008 at 12:00 pm by Chris| When I first picked up Send: The Essential Guide to Email for Office and Home, by David Shipley and Will Schwalbe, I thought it would be a pretty light book telling me lots of obvious stuff I already knew. After all, I send emails all day every day, and have been for a long time. However, I was easily proven wrong. While SEND is a quick and relatively light read, it contains lots of helpful information which I have already put in to practice. Here are five of the main ideas that I'll be sure to keep in mind for my emails from now on: 1. Seniority and "to:" Order This may not be an issue for you or the people you work with. In fact, before reading this in SEND, I never even considered it. However, my feeling is that when it comes to email etiquette, you're better off being safe than sorry. Essentially, Shipley and Schwalbe's point is that when assembling your "To" list of multiple recipients, put the names in order of seniority, if that applies. This is one of those tiny details that you may overlook, but someone else may not. 2. Good Subject Lines This is a pretty simple point to get, especially if you do much with email on hand-held devices (like your Blackberry). Keep your subject simple and on point. If the content of your email has nothing to do with the original subject line of the email string you're still in, go ahead and change it. However, if you use Gmail, keep in mind that the subject line is what Google uses to string emails together in a "conversation," so you may have other reasons to maintain a particular subject. Because we send so many emails, both internally and to our clients, I like to use an "internal" tag when sending emails to Newfangled people that are not related to particular projects. This way, a busy Project Manager can quickly identify my email and prioritize it among the many others from our clients. One of these subject lines might look like this, "Internal: Project Manager Meeting Rescheduled." Likewise, I might tag an email related to a particular project like this, "client.com: Go Live Schedule." 3. To Cc or Not to Cc The Cc field can be a shield, or it can be a sword, so use it with care. Because Cc stands for "carbon copy," the intent was to use this field to include a recipient who may not need to follow up directly on the email's questions or requests, but needs to be kept informed of the information. Using the Cc field can send strong messages, too. If an email conversation with a client gets tense, but you know that you are following the proper protocol, you might Cc your superior on your response. This "shield" approach will communicate to your recipient that you're done playing games and are confident that your superior will back you up if needed. If you do this, be sure you're in the right. On the other hand, if your email is accusatory or corrective toward your recipient and you Cc someone else, you clearly have your "sword" drawn. Be sure you're ready for battle. Lastly, I think it's polite to inform your recipient that you are Cc'ing someone else, and why. If the Cc'ed address is foreign to your recipient, they could immediately be on the defensive even if the don't need to be. In my example below, notice that if I didn't let "Ralph" know why I was Cc'ing Mark, he might get defensive and assume it was a passive aggressive way of complaining about the schedule being off. To: Ralph 4. "There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know." Donald Rumsfeld was given a hard time for this quote, but he's actually right. In fact, one of Eric's favorite quotes ("The biggest problem in communication is the illusion that it has taken place." ) points out that we often assume we know things that we don't, or that others know things that they don't. It's good to know that there are things you don't know- thanks, Rummy! This problem runs rampant in email, so never assume that the recipient of your message will know what you're talking about. Unfortunately, writing a huge email with lots of back-story won't necessarily do the trick either. Because people tend to get so much email now, thorough reading of long emails is not a guarantee. This means that your job is even tougher. You'll need to make sure that your email as comprehensive as needed but also as succinct as possible. Simple tricks like making sure that major points, instructions, or questions have their own line will make it easier for your recipients to pay attention and follow up. Also, if you are sending the email to multiple recipients, try highlighting particular information for them. Below is an example. Notice how I didn't just launch in to my questions without providing some context (the new employees). To: Eric, Mark, Mitch, Katie, Jason 5. Oh no you didn't! Not in My Inbox! Do you ever get emails forwarded to you that include days, weeks or even months of communication that the sender expects you to sort out in order to respond appropriately? Shipley and Schwalbe correctly point out that when this happens, the sender is essentially taking work from their desk and putting it on yours. Don't let senders make you do a ton of work they should have done before emailing you! An appropriate response to an email like this might be as follows in the example below. Notice how I politely bounced that work right back. To: Eddie |
Tags: project-management email business books
 |  |  |  |  |  |
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
| | | | | |
Separation of Work and Home
February 11, 2008 at 4:00 pm by Chris
In a previous post, A Permanent Work in Progress, I mentioned in passing the notion of the line between work and home becoming more blurred:"However, this potential 'omniweb' may not be such a great thing for those of us who like having some boundaries between our work and time off. I can't help but fear that someday 'not having access to my email' or 'not being in cellphone range' might not be valid reasons to not work while on vacation, or that no matter where I am in the world, I might be easily findable. I also wouldn't mind being able to escape from the ubiquity of technology every now and then, either, but from the looks of things this is going to only become more difficult."Recently, though, the Australian government halted plans to deploy BlackBerries to its workers after employees expressed fears that the devices might upset their current balance of work and home life. It seems that the BlackBerry has polarized at least two groups of differing opinion; the first feeling that BlackBerries would make the work day longer since they extend workstation functionality outside of the office, while the second group felt that in doing so it allowed for greater flexibility for schedules and telecommuting. Personally, I can relate to both perspectives. Having a BlackBerry allows for work-related travel while still keeping up with the 150-200 emails I might receive from co-workers and clients a day. This is great since there is nothing worse than returning after traveling for work to a bottomless inbox. However, it's also tempting to want to respond to email after hours, too. Every time my BlackBerry starts blinking after hours, I have to resist the inclination to open it up and deal with whatever messages are there, rather then let them pile up for the morning. I think the key is just being able to turn the thing off, though the cut off point is really up to your individual discretion, and the requirements of your job. Do you feel that having a BlackBerry (or comparable device) has eroded your boundaries? Update: 01/09/2008: Rae at BBGeeks posted an editorial after I "tweeted" a question: "Does your BlackBerry rule your life" and linked to this post. Her editorial here. 02/27/2008: Paul Kedrosky writes "I couldn't help but notice some bearded guy to Ben's (Bernanke) right who was a certifiable Crackberry addict. He was typing up a storm in his lap, showing incoming emails to other people, and generally out of control with email, and ignoring Big Ben." |
Tags: software project-management business
| | | | | |
I've Been Here Before, Haven't I?
January 23, 2008 at 10:00 am by Chris
As part of his general theory of relativity, Einstein suggested that the shape of the universe itself was hyperspherical, meaning that there is no center as such and that the universe would look exactly the same from any point within it. This would mean that one could potentially, assuming a very powerful telescope, look in a straight line through the full extent of the universe and end up at the back of one's own head! Pretty strange right? Very strange. What does this have to do with web development project management, you ask? Well...Sometimes I feel like I'm having this cosmic Einsteinian experience when I get to a certain point in a project- the point when I realize that despite taking every precaution and exerting much effort to avoid the mistakes of the last project, I've actually made many of them again, plus a few new ones! The site is buggy. It looks wrong in some browsers. Time is running out. Everyone is unhappy. It's at this point when I feel like I'm seeing the back of my own head and I ask myself, "how did this happen... again?" There are some troublesome aspects of most projects that will probably never go away. Things like debugging, multiple rounds of QA, and rescheduling will always be a part of project management because not everything is predictable. But some of these things are actually inherently beneficial to the project. 
Let's start with bugs. Bugs are actually not a bad thing (at least, not always a bad thing). In fact, bugs exist because when software is initially designed and developed, not every factor can always be predicted and accounted for. This means that when the first test is run, the bugs are the first indicator of those unpredicted issues and actually help the project to be refined. However, bugs get less and less appreciated the closer the team gets to an important deadline. This is understandable, but sometimes unavoidable because there are often bug-revealing factors that don't come into play until late in a project (delayed access to databases, new requirements, etc.). But if you can prepare your client for these unforseen issues, and bugs in general, everyone will be much happier. Think about it this way: when any company releases some software that is tagged 'BETA,' it is a general warning to any user that they are likely to encounter bugs of some kind. It's kind of like saying, "we know this is unfinished, and we can't promise that using it will be a flawless experience." But, when the software no longer has 'BETA' stuck on it, users are far less forgiving of bugs. For a case in point, I only need two words: Microsoft Vista.The first thing that any of our clients should know when a site is first released is that there will be bugs. This is pretty normal. In fact, most of the time the visual design is not yet applied at this point, so there is definitely a strong BETA vibe going on. I find that if our clients know that bugs are a normal part of the development process, for all the reasons I stated above, encountering them is far less disturbing. (If any of our clients got the impression that our sites would be completely bug-free the first time they were used, we'd be in big trouble.) However, they do rightfully expect that as the visual design is applied and initial bug reports are addressed, that the site will emerge out of "BETA" in time for launch. This all seems pretty straightforward, doesn't it? You're probably wondering, "what's the problem, then?" I agree, which is why I am often caught off guard when, during the home stretch of a project, things get a little tense and I do that bit of self-diagnostic wondering how this all could have been avoided. Often, the one thing that I know could have avoided this situation is the one thing we don't have: Time. 
In all of our project proposals, we schedule time for testing and QA. It is usually the last phase of the project prior to going-live, which means it is often the phase that gets thrown out when a project is down to the wire. What I've learned is that we need to be much more insistent that this phase is kept in place, even if that means the go-live date is delayed. After all, everyone knows that haste makes waste, right? Of all the phases that should have their full allotment of time, the testing and QA phase deserves it the most. Of course, enforcing this is much easier said than done. In order for this to really work, our clients need to feel that the testing and QA phase is just as important as we do. What I have realized is that when I find myself in that recurring moment of "I've been here before, haven't I," it's likely because I have failed to communicate how important the last phase is, and thus failed to win the client to that point of view also. Doh! Now, if only I could reach out far enough in the Universe to slap the back of my own head!We recently created a 'Project Anatomy' document (see left) that includes every possible step for a project that we might work on as a resource for the project managers. For some projects, not every step will be necessary, but following the anatomy as closely as possible will now ensure that testing and QA are definitely performed at various points in the process and are 'non-negotiable' even when time gets crunched. It's hard to say whether this will prevent every future project from bringing its manager to the 'back of the head' moment, but I'm confident that it will be a huge help. |
Tags: web-development strategy design project-management
| | | | | |
Project Management "Wisdom"
December 18, 2007 at 11:30 am by Chris
As a Project Manager here at Newfangled, I have learned a lot- mostly by making mistakes and being corrected by Mark or Eric (nice) or by one of our clients (not so fun). Regardless of how your mistakes are made known to you, learning from experience is probably the most effective method of growth rather than books and or lists of advice about project management. That said, here are some basic points that I would want to share with anyone new to Project Management:Be Clear and Honest Managing expectations is much easier when you have been clear about what you will do and what you can do from the outset. A precisely worded and thorough contract will get the ball rolling right, but will not ensure that a project will go smoothly. You will have many subsequent conversations via phone, email, etc. that will be rife with opportunities for misunderstanding. So, make sure that you follow up any conversation, especially those had over the phone or in person where decisions have been made, with a clear email outlining what was discussed. Also, do your best to read between the lines. If you have any reason to think that a client expects something that you will not deliver, do not wait for them to ask for it. Be as clear as possible about everything that you will do, and when you will deliver it. Communicate Often Most clients will have a preferred method of communication. Whether it is telephone, email, or some other online tool (like Basecamp), try to use their preferred method as often as possible. They will appreciate it, and you will have greater success in reaching them when you need to. If something needs to be communicated, do not wait unless you have good reason to do so. When it comes to everyone's favorite time in a project, the 'home stretch,' do your client or partners a favor and consolidate punch-lists into one communication. It's easy for anyone to get overwhelmed at this point in a project, and having to read through one less email can help. Prioritize and Delegate Hopefully, you've started out with a well-planned project. If so, its stages will be planned based upon what can be done and when, as well as a sense of priorities, which can be influenced by any number of factors (product releases, events, financial timelines, etc.). However, during the project, new tasks will always be introduced that can affect your ability to meet a deadline, so it is important that you can prioritize these tasks well and integrate them in to the overall timeline. Make sure that the way you prioritize tasks benefits everyone involved as best as possible. Your ability to an advocate for yourself, your developers, designers, and your client is critical. Also, be sure to evaluate up front how a newly prioritized task will affect the overall timeline of your project and let everyone on the team know. While everyone is surely capable of realizing that it will, it is your job to put together a plan and deliver the news to everyone on the team.
It's likely that during the course of most projects, you will find yourself in the position of having to deliver bad news. This may be because of a mistake made, a missed deadline, or even false expectations. No matter what the reason is, your success in this project will be determined by how you handle the crises, not the successful parts. Because of this, I would always advise that bad news be delivered over the phone or in person. We all know that it is easier to email bad news because you can be just one step removed from delivering it and almost hide behind the technology. However, my experience has been that this just makes things worse. When you do make the call, apologize and take responsibility when necessary. Acknowledging your mistakes is just the right thing to do, but it also will be appreciated by your client and be a reminder that we are all human and liable to mess up now and again. I hope that some of these points are helpful. I know that after having made the mistakes that lead to these things being evident to me, I would have loved to have considered them beforehand. However, as I said before, experience (especially the tough stuff) is the best teacher. |
Tags: project-management
| | | | | |
RSS