Project Management Is At the basic bottom line, a project is a unit of measurement. It’s used to indicate the beginning and the end of a discrete event or series of events. Projects are usually larger than a single task. Going to get milk isn’t a project. Running a business is also not a project. Starting a business to help people buy milk is a project. A project could be a solo event for just you. For this conversation, let’s assume there are a few people involved. We won’t discuss budget, specifically. Definitions One thing that derails projects is the lack of a discrete beginning or end. Projects either meet with dissatisfaction from their sponsors, or they amble on past deadlines as scope creep locks you, the project manager, into a lengthy and morphing situation of countless follow-up tasks. Here’s a trick. Use this measurement up front: From what to what by when? For example, we will go from having no content management system to having a content management system operational and reachable from the outside world by the 25th of July. The definition isn’t going to replace all the details and requirements of the project, but it becomes helpful in setting expectations. Set Expectations Once a definition is in place, it becomes part of the project manager’s role to make sure everyone is aware of the scope all the time. With a project involving more than one person contributing, and more than one sponsor or boss, it’s important that everyone knows what they’re getting, and is reminded often of the scope of the project. For instance, if you’re delivering a piece of software that different teams can use to maintain a knowledge management site, it should be explicitly stated that you won’t be POPULATING the catalog of data, if that wasn’t in the scope of the project. Other expectations will be around the method for conveying information (a list and a review, mentioned below), for escalating, for handling slipping of any dates, etc. Set Exit Strategies Some of you are saying, Chris– we haven’t even started talking about the project guts and you’re talking about how to get out, and how to make sure you’re not strung along for more. There are countless military histories that suggest that a poorly planned exit is the downfall of many a battle. To me, understanding the end of the story becomes a great driving power to the narrative of the beginning and middle of the story. It’s the same with projects. A good exit strategy will answer the following:
How will everyone know things are completed? Who “OWNS” the new situation once the project is complete? Who signs off that things are complete, and how? What, if any, follow-on activities will be carried into a new project?
A List and a Review If you ask my current VP about project management, he says it boils down to two things: a list, and a meeting to review the list. He is the one who got me in the habit of setting up projects to run like this:
Create Project Documents – The answers to all the above, plus the basic high-level task list, and contact info. Create a Milestone List with Dates and Owners – First run is just making up the overall schedule. Run around and make sure the owners agree to the milestones and the dates. Schedule a Review Meeting – We’ll talk about this next.
The milestone list should be kept in a file format that’s easily shared with all resources. I’m not a big fan of distributing Gantt charts in Microsoft Project. If you are, that’s swell. Another easy fix to this is just a simple 4 column table in Word or PowerPoint or Excel, with a Date column, a Milestone column, an Owner column, and a Status column. The first three are easy. Status can be one of five things: NEW, ON TARGET, BEHIND SCHEDULE, JEOPARDY, or CLOSED. The list becomes the document of record for all parties in the project, including the sponsor. It’s the project manager’s responsibility to manage the list outside the review meeting. This means one-on-one check-ins with the owners of the various milestones, and getting a crisp status for the review meeting. If all goes well, the review meeting should be a simple reading out of the current status on the list. And by reading out, I mean that the project manager has the floor. This is a “nodding heads” meeting, and in setting groundrules, it’s important to get people’s understanding that this meeting isn’t for discussion. It’s a quick, 15 minute or less, ‘in and out’ meeting, to give status in real time, and to hear back from constituents ONLY if there is a show-stopper new development that happened before you as a project manager last touched base with the milestone owners. Milestones and a Project’s Guts You’ll note that I mentioned milestones lists only. I once worked on a fairly complex project, involving millions of dollars of computer hardware and software, upgrades to an operating system, firmware, drivers, the primary database software, and the storage environment, all in the same 2-step maintenance window. We had an outside consultant help with the project planning. He wrote out a 390 task project that took several weeks of revisions and edits and meetings to discuss the new revisions of last week’s edits… TO THE PLAN. It’s a tool, people. Here’s another approach. My now-VP came in on that project with me. We fired the consultant, and then my colleague chucked the plan. He wrote out the 10 most important milestones of the event, we assigned them owners, and the project suddenly felt MUCH more manageable. Assume your team is built with professionals that know their areas of expertise well enough to handle all the little “I’s and T’s” pieces. Instead, work with the owners to boil the tasks into larger clusters, and assign those a single milestone. So, if the fibre optic cables aren’t run on Tuesday, but get in on Wednesday, it doesn’t really mean that the “Install Network to Systems” milestone is off target. Maybe there were other details on the ground level that worked to put this task right again. Don’t be afraid to quiz the owners on the details as part of your walking around to ensure the status is still accurate over the course of a week, but don’t put all those little bits and pieces on the milestone list. For instance, in my super-huge systems project, we boiled that huge project plan down to 10 items. We spoke with the milestone owners and told them, “We believe YOU are the expert, and that YOU know all the details to getting this task done.” We gave them the onus of dotting every “i.” And it worked. They were actually more responsible, and somewhat appreciative that we didn’t run around bothering them with every little micro detail. Meeting Notes Keep these simple, short, and to the point. Publish a copy of the milestone list with any changes of status. Write a quick few notes about any changes to the schedule, any issues to watch. The point is: brevity is better at surfacing issues or concerns. If you write 2000 words just to be thorough about the things that transpired during the meeting, you’ll end up BURYING the important things that others might need to make decisions. Besides, meeting notes should be unnecessary if all the footwork you did to ensure the list is in order was followed by a brief status meeting. There’s not much to discuss. Instead, keep the guts and the details of projects in a project log. This log is more for lessons learned, and for reflection after the fact. It’s important the project manager invest in the log during the project and not just write it up after the fact. Remember, using something that’s searchable is better than writing lessons learned notes into a paper pad and storing them away forever. Use pads for collection, but use something electronic and searchable (try a wiki!) for the business of making this information useful for any follow-on projects. Human Interaction More than anything, what will sink a project or make a project is you, the project manager, and your ability to understand the motivations of the people on your team. What are their incentives? What other pressures do they have that are in opposition to the work you’re asking them to do? What are the staffing levels of their group? How’s their home life? The success of a project, especially around the ever-important and elusive goal of meeting deadlines, usually hinges on people. Are you in tune with the people on your project? Do you know what bothers them about the project? Have you properly praised them at important points in the project? Have you stressed the importance of one part of the project versus the others? Don’t forget the old bit about praising publically and criticizing privately. It’s not the right place and time to complain about someone’s performance at a status meeting surrounded by all their peers. (Unless, of course, this is really the only motivational incentive left in your arsenal). Project management isn’t about manipulation, but it is certainly about influencing people to see your perspective for the needs of the project, and setting them up for success by guiding them accordingly to paths that will lead to your mutual success. And sometimes (PMI people are about to faint), it’s important for you, the project manager, to realize that the people working projects have other tasks to complete on other projects, and they have lives, and that there are other things going on in your resources’ lives than just this project. If sometimes (rarely) there are areas where the person can be given a single break on missing something minor (while still staying the overall project course), relax and be a human about it. Follow Up on the Article There was a lot to digest in this piece, and I’m sure the project managers in the audience would like to disagree a bit. I welcome comments and differences of opinions. How are you getting things done? Further, if you’d like more information or clarification on anything I might have breezed over, please feel free to contact me through the comments and we’ll try and answer all the questions. — Chris Brogan writes about self-improvement and creativity at [chrisbrogan.com]. He will be launching a podcast in May. Stay tuned for details.
