Schedules are about predictability. This may be obvious to you but get lost on the way to the troops. It is always important to talk about rationale. You need to be able to predict product availability so your sales team can sell and your executive team can predict revenues for budgeting and investor purposes. You need to be able to predict integrations points between constituents on your team like QA or docs and development. Your developers need to predict when they need to work harder or longer and when they are done and can go home for the weekend.
Schedules are not rocket science but they do require effort. First you need agreement on what you are building and therefore you need both requirements documents and preliminary engineering specifications and you need them to be consistent. Next you to do project decomposition and there are a lot of books on this subject (just google software project decomposition). Next you must define integration points. Some hints:
- Only schedule 4 days a week
- Update the schedule weekly and do not let slips go unattended
- Don't let people go home if they do not finish their tasks
- Make people sequentialize their tasks even if it takes longer. Mounds of partially completed tasks will result in slips
- Allocate enough time for docs, qa, integration and field test feedback
Many engineers will tell you that software is not schedulable. They are wrong but it something that can only be believed when experienced. Get some people who have done it before as part of your team. Make your first release smaller and eminently accomplishable to help get your team experience. Goals have to be top down but schedules have to be bottoms up --- do not dictate dates.
Persevere.
More later ...
No comments:
Post a Comment