I know what the methodologies and books say about how we're suppose to track maintenance work efforts. However, having researched this fairly extensively and having talked to a number of people who actually do the work, I've found that reality is quite different from theory virtually 99% of the time. What most people do is lump all of the requests into one bucket, i.e., one application, or just under "maintenance." But this does not allow the organization to manage or track the work effort. So my question is this: what is the minimal, most realistic work breakdown structure (or time breakdown) for a system incident request or a mandated system change? I'm anxious to hear how different organizations are handling/ tracking maintenance work efforts. Saving Changes...
Sort By:
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
When I was a CIO we eliminated the word maintenance out of the software vocabulary. Instead we created a change request process that included the following steps:
1. Meet with users to review nature of the request (Application Manager and Head of internal application User Group)
2. Classify and rate the request in terms of: - Defect vs. Enhancement - Impact on · Cost savings · Revenue enhancement · Regulatory compliance · Infrastructure · Etc. - Urgency (on defects) - Structural vs. Cosmetic - Alignment with current business objectives - Correlation with other planned changes
3. Estimate effort to perform the change
4. Rank requests against other outstanding requests
5. Target request for action based on relative ranking and resource availability
6. Present request to cross-functional steering committee (greater than 100 hours) for approval
7. Based on approval, schedule the change and assign resources
Once the change was in the cue it followed our normal change management process. To get this process approved took support of the top management, of which I was a member. It gave us the ability to approach enhancements logically and put the go / no go decision squarely on the shoulders of the user divisions. Hope this helps. Saving Changes...
Anonymous
Thank you very much. That information is helpful. It appears you handled your "maintenance" through the change management process--but how did you know when the project ended? Didn't you need to know much time/work effort was spent for maintenance-type work?
So, do you "lump" it into one bucket? How do you track the PM part of a medium size maintenance request? How do you track a maintenance request that takes 4 hours?
We are trying to put together a template for maintenance in ABT (Niku) Workbench, and want to know what phases, activities and tasks we need to put in there. In our environment, each group does it DIFFERENTLY!! But we can't do that for the template. I'm trying to find out what the "norm" is in other organizations. Any suggestions? Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
We treated maintenance requests like mini projects. Each one had a work plan. Each had tasks assigned to specific staff members. Our formal code library system kept our version control in order. Every maintenance request had a full impact analysis, high level I/O doc and a map into the code. We had a formal testing process that involved the user who had to authorize the move into production. We also had formal back-out procedures as well. Maintenance followed a formal life-cycle approach just like new development. Typically it was smaller in magnitude in terms of complexity and effort. The more complex the request the more formal the project plan. Most of our maintenance requests were under 100 hours. A request of 4 hours would have an impact analysis and work plan that was merely shorter. It was my way of insuring that a 50 hour effort did not come disguised as a 4 hour one. If you get a 4 hour maintenance request you should be able to put together a 1 page workplan in 20 minutes that maps out the effort. If not then the 4 hours is suspect. The temptation is for people to drop their guard on small requests. What happens then is that the documentation is out of date. Bugs get introduced unknowingly and down the road the price is paid. I learned this the hard way believe me. We used a formal project tracking tool and formal source code library tools. Work plans could be in Excel and summarized in the formal system if they were very small. I find that most big tools come with big overhead. Simple is better. The goal is to do the job with quality and that can be achieved a lot of ways. Saving Changes...
Linda HillProgram Manager| MicrosoftRenton, Wa, United States
I am looking for a documented process for maintenance/small projects or a book that will provide me with guidance on creating one. Does anyone know where I might get this type of information.
Thanks Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
Lin,
Here are a few links you might want to explore.
