All: On another thread, someone gave a link to an article that compares Project Mgr and BA responsibilities. That article, as is often done, states that Project Mgrs do the scheduling. However, from what I have seen, the individual who has the strongest understanding of the "As-Is" is the one who should be setting due dates. I have never been exposed to a PM who came anywhere close to fitting this bill. Can anyone explain to me what inputs a PM uses in deciding due dates\schedules? Tony
All:
On another thread, someone gave a link to an article that compares Project Mgr and BA responsibilities. That article, as is often done, states that Project Mgrs do the scheduling. However, from what I have seen, the individual who has the strongest understanding of the "As-Is" is the one who should be setting due dates. I have never been exposed to a PM who came anywhere close to fitting this bill.
Can anyone explain to me what inputs a PM uses in deciding due dates\schedules?
Tony
Hi Tony,
Every good PM I've ever met rarely makes their own estimates - they rely upon the expertise of the team leads from each respective group (BAs, development, testers, etc.) to judge how long their team's tasks will take. In a phased project, they may use what's calling a 'rolling wave' estimate method, whereby they get the BA team to estimate how long it will take to do detailed BA tasks, and only get high level, broad estimates for future work since development time will be greatly dependent on what the BAs uncover and what sort of requirements are signed off on.
The other method, of course, is WAG (Wild Ass Guessing). Most PMs I know have had to resort to this at one point or another, based on their experience on similar projects in the past. Ideally though, they're asking the experts on the team how long it will take to do their work, then simply rolling that information up into a comprehensive project plan/work breakdown schedule.
A very common situation is the internally or externally fixed due date. For example, a new system is needed to support peak season for a company, like Christmas for most retailers. Miss the date, no point in having done the project. Meeting a government legislated deadline is another case.
The key is not to freak out, but to essentially define what can reasonably delivered in the set timeframe, starting with a given set of resources. Use a rule-of-thumb like 25% analysis, 50% development, and 25% testing to divide up the timeframe. Work with the experts to estimate what can be created in such a timeframe. review that with the sponsor; if its not enough, try adding more resources but knowing that there is an upper limit on resources before adding more actually slows things down. Get creative, figure out what can be done in parallel, and have parallel teams/projects.........
Again, the key is not to say that fixed dates are not reasonable, but to work with the business to agree on what can be delivered by a fixed date. I have found that it is almost never completely what is wantedd, but it is enough to meet immediate needs, then add to it in another go-round.
Every good PM I've ever met rarely makes their own estimates - they rely upon the expertise of the team leads from each respective group (BAs, development, testers, etc.) to judge how long their team's tasks will take.
And good team leads will ask their team how long things will take. Note this requires a team to know what activities they are going to do, and so some panning has to take place first.
[QUOTE]larimar wrote
In a phased project, they may use what's calling a 'rolling wave' estimate method, whereby they get the BA team to estimate how long it will take to do detailed BA tasks, and only get high level, broad estimates for future work ....
[/quote]
An excellent way to accomodate uncertainty in the future. You can learn more on tis topic from Johanna Rothman's blog.
Also - anyone care to comment on agile project requirements planning and management procsses for BAs?
brought to you by enabling practitioners & organizations to achieve their goals using: