linaro-project-management team mailing list archive

[Jamie Bennett <jamie.bennett@xxxxxxxxxx>]

On 25 Nov 2010, at 21:07, James Westby wrote:
> On Thu, 25 Nov 2010 17:44:43 +0000, Jamie Bennett <jamie.bennett@xxxxxxxxxx> wrote:
>> The idea of this pilot is to try to use traditional tools and methods to monitor
>> our projects. For this we need a little more up-front from the engineer, usually
>> around estimation and specification. After that, the only thing the engineer has
>> to do is keep the PM up-to-date on the project.
>> 
>> So the steps above in the original email constitutes the loose plan, the success 
>> criteria is if the pilot proves to be an improvement to our tracking efforts, 
>> allows up to produce better reports, especially to non-technical management and 
>> does not disrupt the engineering effort too much. I can write up a proper 
>> proposal tomorrow to explain the exact requirements, implementation and goals of
>> this pilot. I'll send a link when its ready.
> 
> "better reports" is where I have the problem. If we don't know what we
> are trying to get out of the project, then we may not be tracking the
> right things. For instance, we want to ensure that there isn't too much
> overhead on the engineers. How much tracking overhead do they have now?
> How will we know how much it increased? We don't want to be entirely
> subjective about this, as a tripling in overhead may not be the right
> choice, even if engineers don't feel that it is an increase as large as
> that.

Thats the chicken and egg problem. Just because we do not have tools today to track
doesn't mean we cannot subjectively determine if using new tools makes an 
improvement. If we closely monitor the exact overhead of doing this then we can
determine if it is acceptable to add that to the projects time budget.

Let me put this another way. Currently we have:

 * No burndown charts or other methods of easily seeing work that needs to be done.
 * No time-based schedule for the cycle. We have blueprints but no idea what order 
   any of the work will be done in, when it is due, if there are dependences at the
   work item level e.t.c
 * No way of knowing if there is a dependancy problem with engineering time
   i.e. only a specific engineer can do a task but will be busy on another project
   for a length of time.
 * No way of quickly getting a snapshot to determine what was delivered at a given
   moment in time.
 * No way of quickly getting a snapshot to determine if we are likely to deliver
   what we intend.
 * No easy way of getting overall progress information.

I could go on but I hope you get the point.

> It sounds like the project is primarily for the benefit of
> management. At which levels of management do we want this to be used?
> What do they value? Presumably they want accurate information, but there
> is a tradeoff between the amount of information that can be given, and
> the accuracy that it will have.

This is not just for management. I see this as collecting more data and using that
for project management at the engineers level, managers level and at the 
upper-management level to solve the issues highlighted above.

> I look forward to reading your full proposal.

I do not want to spend more time on trying to 'sell' the idea, I'd rather be 
fixing the problem at hand. This is a problem that was highlighted through-out the 
last cycle and is even more important for the coming 6 months. Its a deficiency 
that has been an issue for everyone from engineers right through to upper 
management and our partners, and needs to be addressed as soon as possible. To 
that end I have put together a straw proposal at:

  https://wiki.linaro.org/JamieBennett/ProjectManagementPilot

which I hope is enough to get this moving soon. I have offered to carry the
overhead of helping the engineer(s) to define the specification in a more project
management orientated way, closely monitor the project itself and produce the
post-mortem, this should just be a matter of selecting a project from the
infrastructure team and allocating a minimal amount of time for the reporting
overhead (all time estimations are on the above wiki page).

> Thanks,
> 
> James


Regards,
Jamie.