“Project” is a fearsome word for many in the newspaper business, because it often means extra work that drags on for months with no end in sight, too many headaches and too few rewards. Project management isn’t easy, but it can be satisfying, and careful management can minimize the headaches. What is a project? Let’s start with a definition: In the project-management context, a project is a task outside the routine that involves multiple workers and extended but limited duration. A special task that takes a few days isn’t a project. A new task that becomes permanent isn’t a project. Launching a new niche product is a project. Running the new product after launch isn’t a project, it’s a job. A recurring task that is part of your routine isn’t a project. A special task you handle yourself may be a personal project but doesn’t require all the techniques of project management. A successful project:
Planning your project Identify the need, describe the result. Whether you are proposing a project to your boss or your boss is assigning a project to you or you are assigning a project to someone on your staff, the first step is identifying the need you will address and the result you will pursue. Each of these is critical to your success. If you aren’t addressing a genuine need, you will have trouble persuading anyone to help. Why go to all that work if it’s not necessary? As the project manager, you need to identify and articulate the need. Identify a need of your readers, your advertisers, your employees or your organization that this project will address. The need may be something you are not doing well or at all now. It may be correcting an inefficiency or replacing outmoded equipment. It may be a change in technology or the marketplace that you should address. The need is the problem or opportunity you are going to address. Identifying the need gives your project a cause. Describing the result gives your project a vision. If you are launching a new product, you need to describe what it will be and how it will serve the reader, the advertiser and/or your organization. Even before you have developed a prototype that will clarify the vision, you need a description of the desired result. If you are improving a process, describe how things will work differently. If you are reorganizing a department, describe how the new organization will improve relationships, functions, processes or your product. Another word for your result is your goal. Think of the need as the why of your project and the result as the what. Establish the time frame. A project with no end in sight isn’t a project, it’s a new job. You may not have a precise deadline from the start, but have a general time frame. Are we talking about weeks or months? You’re really managing people. The result will become the focus of much of your work and your team’s work. But Dave Witke, former operations director of the Des Moines Register, cautions against thinking that the project is your primary challenge: “Yeah, you’re managing a project, but what you’re really doing is managing people.” Identify and involve parties with a stake in your project. A stake in your project can be positive or negative. Those who would benefit from the change you envision have an incentive to help if you can help them see the benefit. Those who see a benefit in the status quo have a motive to resist your project. Often they are the same people, so you need to help them see that the benefit of change outweighs the benefit of the status quo. This can be a difficult sell because they have grown comfortable with the status quo, no matter how much they might complain about it. The status quo may annoy them but change scares them and fear trumps annoyance. Among the most significant obstacles projects face is sabotage, active resistance or passive lack of cooperation from parties with a stake in the outcome who haven’t been involved in the project at a level appropriate to their stake. Consider at least all of these possibilities as you survey the landscape for possible stakeholders:
Not all of these parties will necessarily have a stake in every project. Some projects might affect someone not listed here. Find the appropriate level of involvement for stakeholders. Keep the involvement of any stakeholder in line with the stake, role, interest and ability of each party. You don’t want to turn decisions over to readers. But you do want to use reader research that you already have. If your project will produce something new for the reader, you may want to consider new research, whether it’s a survey, a focus group, an online poll or just random informal interviews. If your project is an internal matter that doesn’t directly affect readers, you don’t need to involve them at all. Determining the correct level of involvement for peers and staff members can be more touchy. Some may want more control than is appropriate. Some whose help you may need may not want to be involved. For many stakeholders who are crucial to the success of your project, you need to involve them early enough that they buy in to your project and support it, or at least don’t resist it. Brainstorm the project. Lead an early brainstorming session to discuss ways to do the project. As important as the need and result are to the project, the work of the project is choosing and following the path from need to result. The need and result are easier to see than the path. This is what you seek to find in brainstorming. This meeting should include anyone who will be substantially involved in the project. Be sure to include anyone with a small role that is crucial to the project’s success. The brainstorming session is not a time to push for major decisions, but a time to hear creative, even outrageous ideas. Consider challenges and obstacles that the project presents and seek inventive solutions. Remember: The brainstorming session is not a time to build support for your ideas, but to seek a wide range of ideas. If an idea seems impractical or even impossible, don’t dismiss it right away. Don’t say that it won’t work. Ask what it would take to make the idea work. Take lots of notes during a brainstorming meeting. Write ideas on a flip chart and keep the pages for future reference. Don’t limit the discussion, with one exception: If you or top managers have already made some decisions about how to do the project, be honest about those decisions and encourage discussion within that framework. Workers will rightly resent wasting their time and creativity discussing something when you weren’t going to consider their opinions. Build consensus, but challenge and clarify it. Consensus is a positive result of brainstorming, but you should not reach it lightly. If someone else is not playing the contrarian role by their nature, you need to do it, or ask someone in advance to ask some tough questions. If you reach consensus quickly and without challenge, you may have unanimous support for a simple idea that sounds attractive but is doomed to fail. In brainstorming, you don’t want to reject or embrace ideas immediately. You challenge them, but you don’t shoot them down. If you reach consensus during a brainstorming meeting, clarify what people agree to. Don’t commit, however, to follow that course of action. While consensus is a positive result of brainstorming, the process is not suited to decision-making. You still may need some research, or at least some reflection, before you commit. Don’t dismiss impractical ideas. Most innovations result from ideas that seem on first blush to seem impractical, outrageous or even impossible. Don’t dismiss impractical suggestions right away. Think about them. Don’t say, “That would never work.” Ask, “How would that work?” You make the decisions. The goal itself is usually a management decision. Choosing the path to the goal is a group process, but it’s still your decision. You honestly solicit their views and you should value their advice, but some of their suggestions will conflict and some may not work. You should not go against a consensus without an explanation. But you don’t have to follow every suggestion the group makes. Research thoroughly. Study what your paper has done before. Has someone tried the same thing before? That doesn’t mean you shouldn’t try again, but you should learn from the previous effort. Or previous projects that overlapped with yours might provide some valuable lessons. Try to find out if other newspapers or other businesses in your community have undertaken similar projects that you might learn from. Gather information about costs, reader research, available software and so on that you will need for your project. You don’t have to do all this work yourself, but you need to assign and supervise the research. These are some things that you may need to know to execute your project successfully:
Decide how you will gather and share information. A crucial factor in coordinating the work of the project is the quality of communication. You need to share communication in a timely fashion with members of the project team without swamping them with information they don’t need. You also need to share information with others who will be affected by your project. Even if they aren’t doing the work, they will be interested in your project. Some will make helpful suggestions or point out potential pitfalls you missed. Keeping other departments informed also heads off the possibility of counter or parallel projects. Your communication plan will involve some combination of these methods:
Set a realistic budget. Budgeting is an important part of a project’s success. A lavish budget can mean you don’t get approval for the project. A stingy budget can mean you don’t commit the resources needed for success, or that you succeed in meeting your goals but don’t get full credit because you overspent your budget. Plan realistically for the materials, equipment, consultants, capital and labor (including overtime) involved in your budget. Confer with people who ran similar projects for your paper or other newspapers before and learn what expenses they failed to anticipate and what costs ran over their budgets. Don’t assume (unless you know) that your bosses play the game of cutting a similar amount from any budget, so you put some fat in the initial budget for the boss to cut out. Even if that’s a ritual for the annual budget, it might not be for a project. The boss has to approve an annual budget for your department, and genuine give and take is part of the process, so each side might exaggerate to its own advantage in the process. But your project budget often is part of seeking a yes-or-no answer for the project itself. An inflated budget can result in a turndown, rather than some trims you can live with. Sometimes your budget comes up after the annual budget is set, so you are making the case for every dollar you spend. Or sometimes the project budget becomes a proposal to put into next year’s budget. If you are choosing a path that costs more than some other choices, explain why the benefits of that path justify the costs. Set a deadline. Your project might have a built-in target date. For instance, if you are converting to a new press with a smaller web, your redesign project better be finished when you switch presses. If you don’t have a ready-made deadline, set a target date yourself. It’s easier to enlist help in a project of known duration than in something that could drag on endlessly. Selling your project Sometimes selling the project follows a lot of planning. Sometimes it comes early in the planning stage. If the project is your idea, you will have to sell it to your boss for the project to proceed. If it’s an assignment from your boss or an idea your boss has approved, you will have to sell it to your staff and peers, and perhaps other audiences, for the project to succeed. Plant the seed. If the project is your idea, don’t surprise your boss with a full-blown pitch. Mention the idea first. Say you’re going to look into the possibility. Even if the initial response is cool, the boss has had some time to think about it. A few advance mentions can build some interest or momentum. If you plant the seed adeptly and the boss likes the idea, he can think it’s his own idea, which makes your sale a lot easier. Decide how to pitch the project. You need to assess the audience for your pitch and the best method(s) to persuade your audience. Your pitch can take any or a combination of a variety of forms:
The approach you take will reflect a variety of factors: the nature of the project, your personality, the personality(ies) of your audience, the time that is reasonable to spend in the pitch. Again, identify the need, describe the result. As you do in the plan, your pitch needs to start by clearly identifying the need and helping your audience envision the result. If you don’t help people see the why , you’re wasting your time explaining the how. Be sure that you explain the need and result from the standpoint of your audience. Tell them how the project will help them, not how it will help you. Keep the reader in mind. If you sell your project based on how it benefits the reader, your sale is easier than a pitch based on how it helps you. Don’t over-explain the how. You do need to cover the path from need to result in your pitch, but explain it at a level of detail appropriate to your audience. Anticipate what questions they might have and try to answer them. But don’t bury them in process or minutiae. Help them remember your point. Decide what’s the main point that you want the audience to remember about your proposal. Can you emphasize that with a punch line, a slogan, an exercise, some small gift or a skit, prop, video or music clip that makes the point more memorable? Be sure that the device you use makes the point, rather than distracting from it. You don’t want them to remember a gimmick but forget your point. Keep selling the project. You don’t sell the project just to get people on board. You have to keep them on board. Keep them focused on your goal. Remind them of the need that drives your project. Executing your project The excitement of creative work and the optimism of envisioning the result carry you in the planning stage of your project. Carrying out the project can be more difficult. You have lots of work to do and you might have lots of times to procrastinate. Establish a timetable. A final deadline isn’t enough. Identify some milestones that will mark your progress and set deadlines for them as well. Most projects need a “backout schedule.” This starts from the final deadline and works backwards. To make that final deadline, what do you need achieved by when? Identify and assign tasks. As one distant goal, a project usually appears daunting. You don’t succeed by pursuing the daunting, distant goal. You succeed by breaking the project down into individual tasks and assigning them to people you know can carry them out. Make a list of the steps involved and identify people who are willing and able to carry them out. Make your steps specific: Rather than “select software vendor” as a single step, break it into smaller steps such as “identify software needs,” “research software vendors,” “interview software vendors” (this one is actually multiple steps, one for each potential vendor), “negotiate software contract,” “test software” and so on. Some tasks may require more than one person. In those cases, assign the task to a team, but assign responsibility for execution to an individual. As much as possible, assign people to work on their own ideas. If someone made a great suggestion and he’s qualified to carry it out, or help carry it out, assign him to that part of the project and you will have a greater commitment to getting that piece done. Appoint captains of your sub-teams. If your project is large enough to involve a lot of workers and a lot of jobs, assign teams to various jobs. Name someone to head each team and make that person responsible for completing the work and keeping you informed. Staff your project to get the job done. Are people working on your project while handling their regular duties? Or are they detached to work full-time on the project? Make sure that you have enough people to do the work and that you have enough of their time to do the work. On a small staff, you might have more trouble detaching people from their regular duties. But you will find it harder to make progress if people are juggling your project with daily demands. Try treating your project at times like a vacation or illness. If that worker called in sick today or was on vacation this week, you would somehow get the necessary work done. Sometimes you need to treat the project the same way, at least for a day or two or a week. Regard the person as unavailable for daily duties, just as if he was sick or on vacation. Consider whether you need to add staff for the project, whether as temporary or permanent workers. Consider outside help. Your project might benefit from outside consultants, perhaps for market research or help assessing technology needs. Push the progress along. Especially if your staff is juggling daily duties with your project, you need to pay close attention to the small tasks you have designated. Rather than asking someone if she can finish a big chore by next week, break that chore into smaller tasks and ask if she can finish Task A tomorrow. Then you ask if she can finish Task B the next day. Monitor progress through a chart or spreadsheet or some means of showing yourself and your staff how much you have achieved and how much work remains. Test your solutions. Sometimes, as with new technology, testing is essential before you switch from the old way to the new. Work out the bugs before you’re relying on the equipment. Sometimes you test your solutions by distributing the plan widely and welcoming the (sometimes sarcastic) comments and suggestions. Note milestones. Your project might have some milestones that mark you as halfway done or finished with a key segment. Use these as occasions to praise the workers and refocus on the final result. Meet deadlines. Failure to meet deadlines erodes credibility – your credibility, the project’s credibility and the credibility of future deadlines. On the other hand, inflexibility in the face of legitimate delays hinders teamwork. It’s better to extend a deadline when you recognize a fair cause for delay than to insist on the deadline and miss it (or meet it with slipshod work). It’s also best to move deadlines well in advance, when you can see that the original plan won’t work. When you move a deadline right before you miss it, then you really missed it. Keep the boss informed. Don’t bury your boss in detail (unless she likes being informed at that level), but don’t surprise your boss or keep her guessing. After assigning you to manage the project, the boss also might want to sign off on your plan or some decisions along the way. Tell the boss what you and your team have decided and how you are planning to proceed. Don’t present the boss with options and ask her to make the decision. Leading your team Success rests with your team. The success of your project rests largely with your leadership of the team that will carry it out. Treat your team members as partners rather than minions, Witke advises. Value their ideas. Respect their opinions and their feelings. Keep them informed. Honesty is essential. Some projects will result in permanent changes in some workers’ jobs. Be frank about those possibilities, even the possibility of staff cuts. Workers appreciate honesty. More important, Witke notes, “If people think they’ve been misled, they become obstacles rather than partners.” Workers will speculate about the unpleasant possibilities anyway. Your candor about the changes can provide some motivation for people to perform well because they want to show their value. Praise is essential. Watch for points along the way where you need to give praise and thanks to individuals on your team, to the team as a whole, to others who are supporting the work of the team. Pressure helps, too. Pressure and praise go well together: “That’s a terrific plan. I can’t wait to hear next week how you’re doing on that.” Trust your team. You appreciate your boss trusting you to do this project. Trust the people on your team to carry out their roles in the project. “You can get overwhelmed unless you’re good at delegating,” Witke warns. Commitment leads to cooperation. Make individual assignments early in the work of your project. As people start to invest their own time and effort in the project, they become committed and that commitment is critical to your success. Document your project Put your plans in writing. A written plan helps everyone share the same understanding of the need, the goal and the path. Writing your plan helps refresh memories as you go along, when some people will inevitably forget details. Don’t bury everyone in paperwork, but your project might benefit from any or all of these documents:
Trouble-shooting your project Your project will meet obstacles. If it was easy to do, someone would have done it already. You need a twofold approach to problems: prevention and response. Anticipate and prevent problems. Part of your initial brainstorming and your planning that follows must focus on what problems might arise and how you can head them off. Assess potential obstacles by determining which of these situations they fit:
Watch for turf battles. A colleague who heads another department may want to take over a project or block your efforts. You need to consider whether you are proposing a project that really is someone else’s responsibility. If you really should be the project manager, but the other manager has a genuine stake, you need to negotiate a substantial, appropriate role for the peer in carrying out the project. If this manager does not have a genuine stake in the project, you might have a personality clash or power struggle with him or her. The best way to work this situation out is to deal directly with the other manager. If that is unsuccessful, protect your project by seeking help from someone who supervises both of you. Be ready to respond. Only a fool pretends he can plan thoroughly enough to anticipate and avoid all problems. As important as planning and prevention are, the success of your project will rest more with how you handle problems than how you prevent them. Your project plan needs to include some specific what-ifs as well as a general plan to move swiftly to contain damage and get back on track. Focus your planning and your response to minimize disruption to customers. Fix the problem, not the blame. Disruptions in your project call for calm, decisive leadership, not finger-pointing. Unless you know someone was sabotaging your project (and be sure that’s the case before you accuse anyone), blame is not important. Take responsibility for the solution rather than seeking to assign responsibility for the obstacle. This is where the best project managers shine. Don’t let obstacles become excuses. Unless your project is unusually simple or unusually blessed, you will encounter obstacles. Approach them with the outlook that you will make them part of the war story of your success, rather than using them as excuses for your failure. Creative, determined managers find a way over the obstacle or another route to success. Finishing your project Keep the finish line in sight. As you pursue the project, keep your eye on the final result, so you always know how close you are getting. As you approach completion, review your plans and take care of the remaining details. Wrap up appropriately. The scope and nature of your project will determine how you wrap up. Maybe you wrap up with a lot of fanfare as you launch a new product or a new press. Or maybe you finish with a low-key declaration of success. Maybe you need a post-mortem meeting to discuss how well you achieved your goals, how well you met your budget, what lessons you learned that might help in future projects or in routine operations and what needs you identified that might become the target of future projects. Maybe a report will suffice. Maybe both. Make plans to monitor and adjust. Your project doesn’t finish when you launch it. Make plans to monitor how it works. Every organization has a strong default setting of “the way we’ve always done it.” If you are changing a process, you need to make sure that the operation does not revert soon to old ways. Your plans should include some follow-up, monitoring the success, making adjustments and considering possibilities for future projects to build on your success or address any issues you could not address or failed to improve. Celebrate your success Spread the credit. You will receive plenty of credit if your project was successful. Be sure you spread it around. Workers resent few things more than a manager who hogs the glory for their hard work. Celebrate at an appropriate degree. Decide what’s the right celebration for the scope of your project and the degree of your success. A private gathering or in front of peers? On-site or off? Serious or fun or some of both? Food helps a celebration. You can celebrate with pizza in the office (or donuts or bagels if a morning celebration is more appropriate), a business lunch or a backyard barbecue or fancy dinner with spouses, depending on the scope of the project and the degree of success. If your project has cut into family time, a celebration with spouses is especially appropriate. Gifts may be appropriate. Maybe your team deserves T-shirts proclaiming “I survived the (whatever)” or T-shirts with the front page of the first edition of your niche product. Maybe some humorous trinket might symbolize the project. Or if your project replaced something (perhaps an outdated piece of technology), perhaps pieces of the outmoded equipment could be made into some kind of keepsake. Again, the scope and nature of the project will guide whether you should celebrate with gifts and what kind of gifts are appropriate. Time off may be appropriate. You can’t give everyone who worked hard on the project a week off when it’s done. Some of the staff earned overtime pay for their hard work. Exempt employees just put in long hours. Make sure they get a little time off, even if you have to stagger it. Thank the little people. OK, finishing your project may not merit an Oscar acceptance speech, but be sure to thank the support staff who did the “grunt work” of the project. Praise is also due to those who filled in on regular duties while some people on your team (or you) worked on the project. Learn from failure Your project may not succeed. Or parts of it might not have worked. Study what went wrong. The point here is not finger-pointing, although people need to be held accountable for failure to deliver on promises. Mostly you need to learn how to avoid and address these problems in the future. Understand project fatigue Thank your staff. Some, perhaps all, of your project staff, will be fed up when the project is finished and vow never to do another project. This is natural. Most projects cause post-project traumatic stress disorder. Celebrating is only part of the treatment. Time helps, too. And private thank-yous. Thank each person individually and specifically, in person and in writing, for her contributions. And after you’ve given the frustration some time to pass, thank them all again, when they might appreciate it more. Don’t forget to thank the people who helped by covering the tasks normally assigned to the people who worked on the project. Enjoy your accomplishment. You will suffer project fatigue, too. Recall the need that launched this project in the first place. Reflect on the teamwork that met that need. Observe the result you achieved. Treat yourself – and perhaps someone close to you – to a private indulgence. Thanks to Dave Witke for his advice for this handout and this seminar. My advice reflects Dave’s guidance and example well beyond the quotes attributed to him here. |