I've recently joined a company that has several medium sized (for my industry) projects. The projects are similar in nature, but for different customers - so no merging of projects is possible.
My task is to take over 2 of the projects that are already mature (3rd and 4th year, with releases made each year prior). Both of the these projects are now officially in maintenance.
My problem is this:
The maintenance agreements provides for enhancements to the software (some of the enhancements are documented, but not all are).
There are no existing project or test plans for the software (from any phase) and development is pretty much ad-hoc centered around defect repair and feature addition.
There are no formal PM systems in place for this department (I've recently deployed an issue tracking system and created a test plan template - but adoption is slow). Before that, issues were handled on spreadsheets with no clear indication if they were actual defects or enhancements.
The customers receive "patches" without thorough (sometimes without any) testing and often complain that features that used to work before are now broken or missing altogether (how the customer performed acceptance testing is beyond me).
Since we're in maintenance, there really aren't even concrete dates for delivery (though the customer wants everything yesterday, as usual).
The development team is only part-time on this project (and each member is part-time on at least 1 other project with higher importance).
The requirements are out-of-date, but at did exist at one time for the earlier phases.
Basically, the projects are not managed in the traditional PM sense and I am struggling to bring order without overwhelming everyone with new tools and processes.
What I've done so far:
Created a project plan for 1 of the projects (as if it were a regular project in progress). I plan to do this for the other, but have several hundred software issues to handle ASAP along with a code migration to a new platform.
Deployed an issue tracking system (no longer using spreadsheets).
Have started a test plan centered around the known defects (so we can actually test/verify patches before shipping to the customer).
That being said, I still feel that the projects are mostly out of control and I'm wondering what tool/process to implement next (most bang for the buck) to continue to bring these around.
Any suggestions/ideas?
P.S. My management has been managing these projects, and others like them, in the same ad-hoc fashion for at least 5 years, and doing so quite successfully. I believe this is can be attributed to their in-depth knowledge of the customer and project requirements.
Hi Shawn,
First thing - forget the past - address the future.
In my book the 2 projects you’ve inherited are no longer projects and should be closed. They are maintenance issues and should be treated as maintenance business as usual. Having an incident tracking tool will be a great help.
When I’ve had this situation I’ve planned for a series of maintenance releases throughout the year – say 3 releases per year (max 4). You will need to meet with stakeholders and prioritise for each release – particularly the backlog of incidents.
Each release has a cut off date for inclusion – this becomes the requirements – once you know the requirements you can negotiate for staff resources. If you don’t get the resources you need to be able to drop items from your maintenance release.
You then apply the normal project processes and controls to these. You could maybe get a couple Team Leaders to run these under your mentoring. This will give you time to get your head above the everyday hassle and do a bit of strategic planning.
Hope this helps.
Saving Changes...
I agree with Michael. Using an issue tracking tool is the best approach for documenting requirements and controlling what maintenance release the fix is supplied in. Each release should be treated as a project on its own. This may necessitate some priority being negotiated with the client over reported issues and the maintenance release schedule to accomodate internal development resource constraints. Saving Changes...
