![\"project-management-2-01\"](\"https:\/\/static.jamasoftware.com\/www\/imports\/2014\/03\/project-management-2-01.png\")
<\/p>\n<\/p>\n
In Part 1<\/a> of this series, adapted from my book\u00a0Practical Project Initiation<\/em>, I shared four best practices that can help you lay the foundation for a successful project and two practices that are useful for project planning. This article continues the series by describing additional project planning best practices and several practices for estimating the work needed to complete the project.<\/p>\n Planning the Project\u00a0<\/strong><\/p>\n Practice #7: Develop planning worksheets for common large tasks.<\/strong>\u00a0If your team frequently undertakes certain common tasks\u2014such as implementing a new class, executing a system test cycle, or performing a product build\u2014develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Tailor the worksheets to meet the specific needs of individual projects. I\u2019ve used such worksheets when creating eLearning versions of my training courses. They helped me avoid overlooking an important step in my rush to finish the project.<\/p>\n Practice #8: Plan to do rework after a quality control activity.<\/strong>\u00a0I\u2019ve seen project plans that assumed every test will be a success that lets you move on to the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule should include rework as a discrete task after every quality control task. Base your estimates of rework time on previous experience. If you collect a bit of data, you can calculate the average expected rework effort to correct defects found in various types of work products. And if you don\u2019t have to do any rework after performing a test, great; you\u2019re ahead of schedule on that task. This is permitted in all fifty states and in many other countries. Don\u2019t count on it, though.<\/p>\n Practice #9: Manage project risks.<\/strong>\u00a0If you don\u2019t identify and control project risks, they\u2019ll control you. A risk is a potential problem that could affect the success of your project. It\u2019s a problem that hasn\u2019t happened yet\u2014and you\u2019d like to keep it that way. Simply identifying the possible risk factors isn\u2019t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.<\/p>\n Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities aren\u2019t as effective as you hope.<\/p>\n A simple risk list doesn\u2019t replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. See Chapter 6 of\u00a0Practical Project Initiation<\/em>\u00a0for an overview of software risk management.<\/p>\n Practice #10: Plan time for process improvement.<\/strong>\u00a0Your team members are already swamped with their current project assignments. If you want the group to rise to a higher plane of software development capability, though, you\u2019ll have to invest in process improvement. This means you\u2019ll need to set aside some time from your project schedule for improvement activities. Don\u2019t allocate one hundred percent of your team\u2019s available time to project tasks and then wonder why they don\u2019t make any progress on the improvement initiative.<\/p>\n Some process changes can begin to pay off immediately, but you won\u2019t reap the full benefit from other improvements until the next project. Process improvement is a strategic investment in the organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.<\/p>\n Practice #11: Respect the learning curve.<\/strong>\u00a0The time and money you spend on training, self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you\u2019ll pay a price in terms of a short-term productivity loss\u2014the learning curve\u2014when you first try to apply new processes, tools, or technologies. Don\u2019t expect to get fabulous benefits on the first try, no matter what the tool vendor or the consultant claims. Make sure your managers and customers understand the learning curve as an inescapable consequence of working in a rapidly changing, high-technology field.<\/p>\n Estimating the Work<\/strong><\/p>\n Practice #12: Estimate based on effort, not calendar time.<\/strong>\u00a0People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.<\/p>\n If you track how you actually spend your time at work, you\u2019ll know how many effective weekly project hours you have available on average. Tracking time like this is illuminating. Typically, the effective project time is only perhaps fifty to sixty percent of the nominal time team members spend at work, far less than the assumed one hundred percent effective time on which so many project schedules are planned.<\/p>\n Practice #13: Don\u2019t over-schedule multitasking people.<\/strong>\u00a0The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. Forty hours per week divided by eight is five, right? In reality, she\u2019ll be lucky if she can handle three or four such tasks. There\u2019s just too much friction associated with multitasking.<\/p>\n Some people multitask more efficiently than others, even thriving on it. But if certain of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.<\/p>\n Practice #14: Build training time into the schedule.<\/strong>\u00a0Estimate how much time your team members spend on training activities each year and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.<\/p>\n Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company\u2019s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the student puts the knowledge to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.<\/p>\n Practice #15: Record estimates and how you derived them.<\/strong>\u00a0When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is naturally skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organization can use.<\/p>\n The Wideband Delphi method is an effective group estimation technique. This technique asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. Chapter 11 of\u00a0Practical Project Initiation<\/em>\u00a0presents a tutorial on the Wideband Delphi estimation method.<\/p>\n The final article in this series will describe two additional estimation tips, along with several good practices for tracking your progress and learning how to plan and manage future projects more effectively.<\/p>\n Also read\u00a0Project Management Best Practices, Part 1<\/a> Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.\u00a0 Karl Wiegers is an independent consultant and not an employee of Jama. \u00a0He can be reached at\u00a0http:\/\/www.processimpact.com<\/a>.\u00a0 Enjoy these free\u00a0requirements management resources<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" In Part 1 of this series, adapted from my book\u00a0Practical Project Initiation, I shared four best practices that can help you lay the foundation for a successful project and two practices that are useful for project planning. This article continues the series by describing additional project planning best practices and several practices for estimating the […]<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[72],"tags":[49,51,38,122,24],"industry":[],"class_list":["post-13041","post","type-post","status-publish","format-standard","hentry","category-product-development-and-management","tag-best-practices","tag-business-requirements","tag-karl-wiegers","tag-pm-best-practices","tag-project-management"],"acf":[],"yoast_head":"\n
\n<\/a>Also read\u00a0Project Management Best Practices, Part 3<\/a><\/p>\n