Why Schedule

What a question! Why even mess with all the details of trying to figure out what real dates a project scheduling algorithm tells us the project can be finished by, when the date will be declared unacceptable and pulled up anyway? This is a real problem facing many software development project managers today. They think, "Why not just slap the date they want up there and 'just do it' anyway you can, starting

This attitude results from a lack of understanding of what a real project schedule is, on the part of the customer, sponsor, and the project manager. The big picture of the project is contained in the software development project plan. It describes how the project objectives (the what) can be met. One element of that is the schedule. It reflects all the relationships of all the activities, as best understood by the project team, mapped to a real-world calendar that comprehends true productive working hours, and allows for the inevitable uncertainty of the future. Normally, the schedule (usually expressed as a Gantt chart) is made an appendix to the SPMP. This is because it is a relatively volatile part of the plan, getting updated frequently during the tracking of the project. For any document, things that get updated a lot should be part of an appendix, because they are easier to maintain that way.

The Game

The lack of understanding of the true nature of a project schedule, and how it is built, causes management to see it as some kind of black magic, where they see a bunch of requirements go in, some hocus pocus with formulas and function points happens, and a date pops out, along with resource needs (cost = money). These are the three parts of the triple constraint (scope, schedule, and cost). Since software development is mostly a people-intensive process, managers and customers often play a game where whatever date and cost pops out, they will ask for it cheaper and sooner, thus getting the best possible price and schedule from the project team. Knowing this, many project managers pad their estimates and plans, expecting a demand for cuts. And so the game is played on both sides, padding and cutting, until an agreement is reached, or exhaustion occurs.

The right approach is to use the project team's deeper understanding of the tools and problem space to craft a realistic schedule based on solid estimating (Chapters 10 and 1_1_) and scheduling (Chapters 8. 9, |2, |3,14, and|5) methods. These can be defended because they are based on the best facts and methods available (and can be demonstrated). The schedule should be aggressive, reflecting a healthy work ethic, but realistic. It should understand that no one works 100 percent of their time on anything, over a long period. Due to vacations, illness, personal time off, interruptions, legacy system support, mentoring, job changes, and a host of similar reasons, the average productive time of an individual developer available to any given project is about 60 to 70 percent of their expected work hours over a year. For someone whose workday is 8 a.m. to 5 p.m. for a 40-hour workweek for 52 weeks a year, this is (40x52 =) 2,080 hours, and 60 to 70 percent of that is 1,248 to 1,456 hours per year, or 24 to 28 hours per week. If you can get more than that, that's great. It will give you some lift and perhaps allow an early finish or additional features in the final product. But if you get less than that, others on your project team will be pressed to make up the slack to meet due dates (that you and the team committed to), and you will experience pressure, overtime, team disharmony, and perhaps product quality problems.

4 previous

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment