Project Management without a Process: Desk Drawer Projects
By J. Romanelli
One of the first reads of almost every IT project management course is the1995 report from The Standish Group titled, CHAOS. This report focuses on the causes and challenges of IT project failures. The criteria used by the Standish Group to determine a project failure is cost overrun, time overrun and content deficiency. In 2004 The Standish Group reported that 53% of projects are challenged, which is no change from their 1995 report. It is obvious through the CHAOS report that challenged projects will violate one or more of the three constraints. One type of project that is inherently challenged is the desk drawer project.
Many software development companies encourage activities like ping pong for developers which provides a therapeutic outlet when they are stonewalled with coding problems. Sometimes a programmer will initiate a desk drawer project as a therapeutic coding project, much like ping pong. The goal is usually to solve some type of nuisance problem. The therapeutic value is the sovereignty during the development and accomplishment of the task afforded to the developer. If all goes well these little gems are usually unearthed at an opportune time, (from the developer’s perspective) solving an issue or a portion of a larger problem. If things do not go so well the project is discovered at some level of immaturity and thrust into a full fledged project. The intent of this paper is to recognize the existence of desk drawer projects, not to justify them. It is the author’s opinion that desk drawer projects can be very valuable to any organization. However, the risks of such projects are huge and must not be ignored.
The risks of desk drawer projects are numerous. Some of the more significant risks are minimal stakeholder involvement, narrow or unfocused requirements, no management support, and little or no planning. Most developers will start their desk drawer project under the consensus of individuals they interact with which leaves a large number of identified stakeholders uninvolved. The narrowly scoped requirements are natural fallout from the lack of stakeholders. It is a rare manager that would support the effort as “project” without a plan, charter or scope. The nature of the desk drawer project makes these risk factors inherent to the process.
The four factors identified above total nearly 43% of project challenges according to The Standish Group. Remember 53% of all IT projects are challenged. A desk drawer project is challenged because it has no project management process which is probably the reason that makes them so attractive to developers. It is the developers’ quiet rebellion against the constraints of time and cost. If done properly desk drawer projects can deliver valuable solutions that patch issues, fill gaps or possibly be integrated into a larger application. It would be difficult to place a value on these projects because the time used to create them might have been lost to some other less productive activity like ping pong. Desk drawer projects are not for every developer, each one will have their own therapeutic process whether or not it is productive.
There are some simple guidelines that can manage the risks of desk drawer projects. Allow the desk drawer projects to exist. Disallowing these projects will not prevent their existence. Request developer disclosure to supervision. This may not be that intrusive, many developers usually let their supervisor know they are working a nuisance problem on the side. Permit only one desk drawer project at a time. Too many projects may cause a sense of overload and dilute from the projects that do have constraints. Be sure to allow the same time allotment and rules as any other therapeutic activities such as ping pong. Do not impose delivery constraints. Create a process for converting a desk drawer project into a full project. Of all the challenges to make a desk drawer project work the biggest challenge will be establishing a discipline.
References
Fuller, R. T., Shafer, D. F., Safer, L. I. (2002). Quality Software Project Management. Prentice Hall (eBook). Database Proquest
Rosenberg, S. (2007). Dreaming in code. New York: Crown Publishing
Schwalbe, K. (2006). Project Information Technology Management (4th Ed), Boston: Course Technology
Standish Group, The (1995). Standish Group Report: CHAOS. Retrieved September 4, 2004 from http://www.projectsmart.co.uk/docs/chaos_report.pdf
