Taking over Problem Projects

Over the years, this happened more and more. Projects, which were started earlier in good faith and full optimism, started to get problematic and the customer hired me in to continue the project and "... get the thing done ...". In those cases, I come new in a project and see people for the first time and there are of course no statistics collected. In those cases I always take a time-out for the project and start multiple processes at the same time. I need statistics about the resources, so I create small projects for the developers to let them work and in this way I can start collecting statistical data about the developers and QC people. I use my normal statistical and cheating methods to check on the QC and then I start using different methods to correct the estimates. The initial data here in this case must come from the Planning Poker method, where I use the Project Members to create estimates. Parallel I use the Wide Delphy method, which contains experts, which are outside the project (and preferable outside the company). The statistics about the QC are here the most important one, because the QC statistics per module, and upward the program(s) and system(s) define if the actual product or parts of the product can be used in the project or not. Also the design will be taken apart. Is the design correct or are there problems in it? The QC statistics will easily point out that the requirements are correct and the system already in place is according those requirements or not, and that is the same for the functional specifications and the technical specifications. In those cases, a tight, pyramid organization model will be implemented (normally I prefer a flat model), where the project organization is being reorganized. When that is done and completed, the project documentation (design, specifications and project plan is resubmitted to the customer and/or senior management and the project continues, but this time on a healthy basis.

No comments:

Post a Comment