General information
Category:
Contracts, agreements and general business
>>What's always worked for me:
>>
>>- Identify every task
>>- Every task MUST have a deliverable
>
>I agree entirely! However, that can be, in itself, a major project when dealing with a large development.
Certainly; it's a function of analysis and design. It's the plan that drives subsequent development. And if the analyst(s) / designer(s) were not competent ...
>>- Use project management software for precedence diagramming, critical path analysis, resource allocation / leveling, progress monitoring
>
>This is a little harder. As I said at the start, the snage with measuring progress in software projects is that it is rarely 'linear'. YOu can be 80% done after 1 day and still miss a 4-day deliverable <s>
It's simply not practical to manage a project with 10 - 20 resources and hundreds of activities "manually"; that's why I advocate PM software. It's no substitute for intelligence and skill; it simply helps with the drudgery.
At any given time, there are still only a limited number of tasks under direct focus which are manageable due to the (maximum) "4-day" production schedule of any given deliverable. The "small deliverables" are so visible, there is rarely a problem or issue of "percentage complete" ... since they are so small, it is very easy to get them back on track, typically with a bit of assistance from the PM / Project Leader.
>Agreed! This is in line with all good practice. Do you also advocate "weekly builds"? (That is something that I like to see too because it helps keeps people focused on 'shipping').
Generally, there is a "user schedule" that runs in parallel with the production of the deliverables. I'm for a staged releases, so the user is intimately involved in integration / subsystem testing. The users become familiar with the system even while it is still in development as each "subsystem" is released. There is not so much a "weekly build" as there is a subsystem build as each subsystem is assembled. Typically, the "master file" subsystems are released first; it's an excellent way to get users creating production-class "test" data for the development team.
>Not so sure about this one. I would prefer to have developers fix bugs that come up during integration. Once past that point I would hand it over to the 'maintenance' team.
It's part of change control. As "project leader" I typically handle this. Users come to me with issues and I handle them, instead of "pulling" a programmer off what they are doing, interupting their current train of thought, and having them visit a program they may have been working on a month or more ago. It's simply more efficient this way.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only