Small Projects and Support Work
An interesting question is the authors' position on the matter of how small projects and support work should be treated. In many IT shops, the same set of people is responsible for both projects of some size as well as support work. In this case, support work may be defined as short-run, project-like non-discretionary work necessary to keep normal operational work going. An example might be a discrete task of, say, less than 25 man-hours to fix an outage, or hardware or software failure.
From a management perspective, it would make more sense for the two types of work to be separated and staffed by different groups of people. At least that would permit the project work to proceed with out frequent interruption, and increase the probability of completing the project on time and with less ambiguity as to the project's time (or cost) investment. However, two things militate against this option. If the shop is relatively small, the "support work", even with "small" projects included, may not be sufficient to make full time work for dedicated personnel, especially if several distinct skills are involved. Secondly, where only a few people have specialist knowledge, of a database or system for example, such people must be available to work on both support-type work as well as on new projects.
Indeed, the authors go further. In the Discussion of this Issue they observe:
"In IT, small projects that involve a short period of time and very limited resources are often not treated as projects at all. Instead, they are treated as normal work. If an IT group has a rigid, bureaucratic project management methodology in place, then managers and staff will potentially take efforts not to label the work a project. They know that if it is called a project, a huge burden will come down on top of the work [delaying] the work and the results. [However,] the impact of having small projects not being projects is that they are almost totally uncontrolled."[11]
The authors emphasize this point by including a graphic displaying the following distribution of effort: Large projects 40%; Small projects 20%; and Support work 40%. The point of the graphic is that in this scenario, 60% of the work is not being effectively controlled. Or, to put it another way, 60% of the work is escaping under the radar.
"Huge burden" may be a bit if an exaggeration, but relative to the size of a "small" project, it is probably not. Perhaps more importantly, but not mentioned by the authors but nevertheless that we have encountered, is the opportunity for individuals to "escape". If switching from project work to "Other work" is indiscriminate, and if the project work becomes tough sledding, then it is possible for individuals to escape by engaging in more routine and comfortable work under the guise of necessary or urgent maintenance.
So, the authors are unequivocal on this point. They say that:
"Our experience indicates that the best long-term approach is to treat all work as projects. This will give you more control of the work. However, that said, it can only work if you have a flexible and - this is important - scalable project management methodology. If you have project templates, a standard issues database, and lessons learned, then this can be done. Any project has a list of open issues. You can scale up documentation, reviews, etc. based on the number, type, and importance of the project or work. If you cannot do this action, then at least impose some minimal structure on small projects [by having]:
- Standardized list of tasks
- Shared issues with larger projects
- Regular but streamlined project reporting
- Planning at the start on issues, purpose, and scope."[12]
In the final chapter the book, Chapter 18, the authors explain the Issue of How Operations and Maintenance Should Be Managed.[13] At the end of the chapter, they conclude:
"A basic point of this chapter has been that support, operations, and maintenance have to be managed as well as projects. It is best if they are managed like small projects. This is easier than you think, since IT is already geared up for projects."
All good advice indeed.[14]
11. Ibid, p141
12. Ibid, p142
13. Ibid, p308
14. Ibid, p310
|
What
We Liked
