The two most scrutinized aspects of a project are whether it came in on budget and on schedule. We discussed yesterday the wisdom of including a contingency fund in your financials for the inevitable added expenses that arise during a project. It's tougher to do that with time. True, time is money, but executives expect you to be able to squeeze a few extra hours here and there from the team to make your timeline. So, getting the schedule right (or at least as right as possible) is a must.
The presentation Scheduling: What Comes Next?, from our partners at gantthead.com, addresses many of the key issues in creating accurate schedules that match your company's development and political climates. The 31-page PDF, which is the outline of a webinar, is available free to IT Business Edge members here in the IT Downloads library.
The presentation walks through the specific challenges of creating effective schedules, which in many ways is tougher than managing deliverables inside the development team. Certainly, writing and testing quality code is a higher-level skill, but there's an art to getting a bunch of business managers to understand and agree on anything.
As you can see in the image below, the schedule in one project area that ultimately is impacted not only by people not in IT, but not even on the extended project. Somewhere there is a vice president who has never heard of your project who will want to know exactly why it is late.
The presentation goes on to discuss the impact of your company's development methodology on how you build your schedule. Certainly, the frequency and extent of internal review and reporting you require will either add or cut time from the development loop. The stridency with which you adhere to a given methodology also will impact how much you can deviate from normal practices to accelerate some project phases.
Another tricky issue addressed by the presentation is the issue of keeping two separate schedules: one for a detailed work plan breakdown and one for general reporting up purposes. By and large, "keeping two sets of books" is viewed dimly by executives, and you may well be better off simply rolling up your detailed schedule into an overview as is often preferred. However, you must remember the intended audience for your schedules. Sometimes grouping deliverables differently to illustrate progress is not such a bad idea-so long as you clearly disclaim you are doing so. And a project might involve two teams with such disparate structures that there's really no choice to maintain two schedules.
The presentation concludes by touching on scheduling software choices and setting expectations, one of the most important aspects of any scheduling process.