James, I think the idea is to see if we can improve a number of areas of projects - and I think we have briefly discussed this in passing before. I think we want to see if we can give management better visibility of project status (the burndown charts are useful, but don't provide a full picture). I would also like to see this benefit the engineers as well - so they can see the workload they have, and management can ensure an individual isn't overworked.
However, all this might be perceived as being onerous on the engineer, and whilst I think a little more information will be required from the engineer, hopefully this will be minimal. The tool, the results, and any feedback from the engineers and management are all part of the reasons for picking a small project that we can monitor without being too much of a culture shock. This should allow us to tailor our toolsto better support the business with minimal effort from the engineers. Does that explain what we are looking to achieve and the additional input from the engineer? Do let me know if you have any questions. Kind Regards, Ian On 25/11/10 15:39, James Westby wrote: > [ Copying Ian who has also been looking at this ] > > On Wed, 24 Nov 2010 20:49:55 +0000, Jamie Bennett <jamie.benn...@linaro.org> > wrote: >> Hi, >> >> Improving our project management techniques will always be an ongoing >> process. >> Linaro, coming from the Ubuntu background, has no real formal methods for >> tracking work done, work in progress, asset utilisation, delivery and >> predicability. I would like to change that. >> >> I'd like to propose that we choose a small project to test out the theory >> that >> traditional project management tools can work with big open source projects. >> Given the short one-month cycles that the Infrastructure currently operate I >> suggest that we pilot this here. Can we select a project from the next >> stake-holder meeting outcome and work to produce valid Gantt information [1], >> use regular monitoring and produce feedback? I am willing to take the >> overhead >> on setting everything up, leading the monitoring effort and provide the >> analysis at the end. >> >> Specifically I'd like to do the following: >> >> * Use OpenProj [2] to setup the initial structure. >> * Work with the implementor(s) to define the requirements and gather timing >> data at the beginning or the project. >> * Regularly monitor the project against the requirements and timing data. >> * Regularly produce a professional report on the progress of the project. >> * Produce a post-mortem to determine if we would like to carry this on, with >> or without improvements, to a further pilot project(s). >> >> How does this sound to everyone else? > I agree that Infrastructure would be a good place to pilot > this. However, I want us to be clearer on what the goals are before we > run an experiment. > > What are you trying to achieve by making these changes? > > It's pretty clear there are going to be tradeoffs here, but we need to > know what to monitor to ensure that we can make an evaluation based on > all the information. > > Thanks, > > James
_______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : linaro-project-management@lists.launchpad.net Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
