I have observed hundreds of projects, including company start-ups, product introductions, mergers, acquisitions, initial public offerings, other financial transactions, software development projects, turnarounds, and construction of an office building. Based on my observations, I believe there are several fundamental rules for successful projects, most of which are applicable to most projects. I call these "Mitchell's Sixty-three Rules for Successful Projects."

1. Start with a good idea. The idea should be challenging (otherwise, others can copy you too easily) but not impossible (either in scope or timeframe).
2. Identify what is important and what is not. Eliminate all "gold plating." In a software project, for example, certain features should be saved for the next version.
3. Devise a sensible strategy that is consistent with your available resources and the external environment.
4. Anything that can be done before you officially begin should be. Once you begin the project, the clock starts ticking.
5. Write down your idea, strategy and operational plan in a business plan or other document. Writing it down forces you to crystallize your thinking. Make sure everyone = clients, team members, management, etc. = agrees to the end goal before doing the detailed project planning.
6. Solicit comments from others on your plan, and revise the plan as many times as needed, based on the comments you find worthwhile.
7. If the project is long-term, consider whether it is possible to break down the project into separate deliverables or end products. A software package, for example, will consist of several releases over a decade, with each version being a deliverable. For each version, decide if certain functionality can be delayed until the next version. Harry Lewis, the former CIO of Chrysler, had a rule that no software project could last more than 6 months; if a project was going to last, say, 9 months, it would be broken into two separate projects.
8. Break the project down into various steps and milestones. Each milestone should represent a short amount of time, typically a few weeks or months at most. Make the criteria for success for each milestone clear and unambiguous — success in meeting that milestone cannot be fudged.
9. Show the milestone deadlines to everyone who must meet a target date and get their agreement that achieving it is feasible. Have all stakeholders sign off on the detailed plan before resources are committed and work commences.
10. Make sure the timetable for the project is reasonable, and include contingencies if certain steps take longer than expected. Identify the critical path and create a contingency plan showing how the pace may be accelerated if required.
11. When preparing the schedule, take into account vacations, inefficiencies, downtime, training, and the fact that people don't and can't work 100 percent of the time. Fudge factors should be included. (One that I use is to multiply the amount of work by 1.5 for every layer of management that must be satisfied with the work.)
12. The project will have a champion who has sufficient clout in the organization.
13. Obtain adequate funding for the project, internally or externally. Although there are several examples of successful bootstraps or "skunkworks," this can only be taken so far. If required, bring in outside investors.
14. A "bootstrap" should never be attempted for a rollup. Rollups are simply too complex, and the time pressures to close too great, to attempt such a complex project without more than adequate financing.
15. Assemble a team. Few ambitious projects can be successfully completed by one person.
16. Each of the team members is passionate and enthusiastic about the project.
17. From the resource plan, make sure the team has a sufficient number of people to complete the project, assuming everyone works hard. Slight or moderate understaffing is often acceptable, but gross understaffing is not. Overstaffing is undesirable.
18. Ensure that the team has the right mix of senior to junior personnel with not too many "chiefs" or "Indians."
19. The team should comprise exceptionally talented individuals who have complementary skills. Choose people who are team players. Each of the members must respect each other and appreciate the unique skills and background the other team members bring to the project. It is preferable to have a group of people who has worked together before.
20. Determine if the team has all of the skills necessary to complete the project. Otherwise, arrange for the team to obtain any deficient skills on the outside. In some cases, it may be appropriate for some team members to undergo some training, assuming the training is not too lengthy.
21. The team should be kept together for as long as it takes to do the job. Turnover among team members should be kept to an absolute minimum.
22. Clearly define management authority. Most projects need a quarterback, but occasionally other forms of project governance have worked.
23. 23. Select a quarterback who has successfully managed projects of similar or greater complexity in the past. This quarterback should be a leader, rather than just an administrator or a bureaucrat.
24. This quarterback should be respected within the organization and is respected by the team members. He is energetic and is a doer.
25. For certain projects, two leaders may be appropriate. The most common example of this is when you have an "outside" manager combined with an "inside" manager. In other cases, there is a logical division among responsibilities. Kensington's rollups, for example, have two leaders: the CEO of the public company, who before the IPO spends most of his time with the sellers, and the Managing Director, who spends most of his time managing the deal and the consolidation team, and talking with underwriters.
26. In some projects, there may be a design or "vision" leader combined with an administrative leader. This is how the Windows NT development team should have been organized. David Cutler is the smartest and most experienced operating system developer/project leader in the world, but he hates paperwork. Microsoft should have appointed a great manager at the same level as Cutler, letting Cutler focus on what he does best, while letting the manager handle all administrative aspects of the project.
27. 27. The organization should have formal training programs for project managers, which are taught by the best and most experienced project managers. In addition, the organization has distilled its best practices concerning project management into a manual (paper or on-line), which is kept up-to-date.
28. 28. The organization should value project management as a logical step on a career path. It should not be viewed as a "dead end."
29. Clearly define who is responsible for each step and eliminate any ambiguity as to who should do what. Each team member should be held accountable for his work by the other team members. Make sure each member clearly understands these responsibilities before work commences.
30. Select core team members who will be totally committed to the project. Make certain they have a meaningful investment (both financially and emotionally) in the project, and provide significant upside if the project is successful. Have them work full-time (i.e., 60 hours a week or more).
31. Team members should not have other time commitments nor should they be assigned to other projects. However, if they were drawn from other departments or organizations, it may be desirable for them to visit periodically with their department or organization.
32. Hire good support personnel as needed. These support staff might include secretaries, a bookkeeper if needed, even part-time housekeepers for personal use. Do not allow highly skilled and valuable core members to waste their time photocopying, paying bills, ordering office supplies, or even doing their own laundry.
33. Add other part-time individuals (e.g., Board members, consultants, technical advisors) as necessary. Understand, however, that these people are part-timers and thus are not as committed as the full-time members. They can help the project succeed, but the core team members are the horses who will determine whether the project is successful.
34. The team should have a set of fundamental principles on which there is no compromise.
35. Team members should put the interests of the customer or client first, the organization second, the team third, and their own interests last.
36. Team members should be brutally honest with each other about the progress they and the team are making, and what they expect of other team members. There should be no surprises.
37. Encourage team members to regularly help each other out, as circumstances and skill sets permit. There should be no "this is my department and that is your department" mentality.
38. Carefully select tools that the team can use to increase productivity. Ideally, the team will have experience with most of these tools, and therefore team members are using only one or two tools that it is not familiar with.
39. Pay sufficient attention to the organizational and administrative aspects of the project. Set up systems to have the routine details, and then delegate as much as possible to support staff. Do not let the paperwork and administrative details get too far behind, or they will bury you. One rule I use is that 1 day a week plus 1 hour a day should be set aside for paperwork and administrative details. (If you have a really good administrative assistant, however, the amount of time you spend on paperwork can be substantially reduced.)
40. The project manager should insulate the team members from unproductive demands on team members' time. Formal meetings and paperwork are kept to an absolute minimum. The project manager believes his job is to run interference for the team members so that they can get their job done. Tom Hout, a retired BCG partner, uses the analogy of the pit crew for the Indy 500 — there is no doubt what their purpose is.
41. If the project will need support from other departments or organizations, that support should be forthcoming.
42. Just as the team members are insulated from time wasters, the organization does not place undue burdens on the project manager. The project manager should be able to spend most of his time managing the project.
43. Unless there is a compelling business reason not to (e.g., you need a representative in another city), the core team members should work out of the same office. It is very difficult to built a successful and distinct culture in multiple locations, particularly at the beginning. That a core team member does not want to move is not a sufficiently good reason to make an exception.
44. The office space should not be cramped and should be designed to facilitate collaboration and information flow. Each professional should have his own private office (rather than a cubicle).
45. Establish a solid infrastructure — good computer and telecommunication systems, sufficient office equipment and furniture, reference material, etc. — that will support the activities of the team. Place particular emphasis on infrastructure that fosters communication among team members, such e-mail and bulletin board software.
46. The team should have excellent local area network ("LAN") and server software, and each member should have his own networked workstation).
47. Each team member should have excellent computer skills which will permit him to utilize such information systems.
48. The team should utilize groupware software (such as Lotus Domino/Notes or Microsoft Exchange) to facilitate the sharing of information and documents among team members.
49. Make all information available to all core team members; there should be no secrets. Ensure that everyone is operating off the same data. Ideally, such information is easily shared through database and groupware technology.
50. If the project involves extensive communication with individuals outside the team, there should be a centralized information system which enables team members to track comments by these outside individuals (such as a contact management system such as Act! or GoldMine).
51. If there are outside professionals (e.g., attorneys, accountants, investment bankers, etc.) who will be part of the project and you will be exchanging computer files with them, try to standardize on which software packages you use, since conversions often introduce problems. Establish communication and information systems and procedures so that they have access to your data, and vice versa. Make certain these outsiders are also committed and adequately staffed. These outsiders do not need to work onsite.
52. Periodically review the project's progress. Develop some kind of system to chart progress, such as a Gantt chart or a project management system. Make this chart visual and accessible by all team members so they can track the progress of the project.
53. If the cost of the project is important to track, establish some kind of automated accounting and budgeting system so that appropriate tracking can occur with little effort.
54. Regularly evaluate the strategy, mission, and tactics of the project as progress is made and circumstances change. As these change, revise the business plan.
55. Ensure that the team is sufficiently attuned to changes in the external environment, and adjusts its strategy accordingly.
56. Regularly solicit suggestions, comments, and feedback from the core team members and outsiders. Carefully listen to and evaluate these suggestions.
57. Market and promote the team and its mission to customers, the organization and outsiders. Keep them apprised of the team's progress.
58. Build team identity through informal gatherings, group exercises, off-site retreats, and other measures. In software projects, for example, it is common for all team members to receive a tee shirt displaying the team's logo. Try to establish a distinct team culture.
59. There should be no politicking among team members.
60. Make small, periodic rewards or other acknowledgments of progress to team members who do a particularly good job. These rewards need not be lavish.
61. For repetitive projects, tools and other forms of intellectual capital will have been developed to make future projects more efficient. Assuming additional projects are anticipated, the team should develop this intellectual capital during or after the project.
62. Base any decision to make an exception to these rules on experience and empirical data, rather than wishful thinking.
63. At the end of the project, do a written post-mortem to answer the question, "What will you do differently next time?"

When you undertake an ambitious project, it is important that each team member put the interests of the project ahead of his own. When we have heard people propose altering these rules, in many cases what was driving them was the fact that they were putting their interests ahead of the project.

Read James' essay on the importance of secretaries.

April 14, 1998, version 1.2   |    List of other essays written by James Mitchell    |    Copyright notice

Cite as “Checklist for Successful Projects ” by James Mitchell. April 14, 1998, version 1.2.
www.BostonConvivium.com/jm_essays/successful_projects.