The spectrum of innovation in IT project management
Posted by Arjun ThomasAn interesting article that I came across on tech republic by Rick Freedman
There’s a constant lively debate in the IT project management community about methodologies. Light or heavy, agile or predictive, canned or self-developed, PMBOK or Prince2; project managers can debate these questions ad infinitum, and then come back for more.
As I discussed last week, the debate over balancing rigor with speed and flexibility also continues. Some project managers advocate following strict Project Management Institute (PMI) principles even for the smallest projects; others insist that qualified technicians should be able to manage their own efforts, and project managers should focus on team leadership and client relationships. Rather than argue these well-worn points, let’s explore one key criteria that drives the selection of a project approach: innovation.
The broad spectrum
Most projects fit into a broad spectrum of innovativeness. On one end of the spectrum is the most mundane, repetitive project a project manager might be asked to undertake, such as a desktop migration to a new application revision. Calling this project mundane does not imply that it’s without risk, or that it doesn’t require management; even the most routine project can be fraught with unknowns. For these sorts of projects, many project stakeholders and sponsors expect to see minimal project overhead and assume that, since you’ve done it so many times before, it will follow a preconceived plan and approach.
On the other end of the spectrum is the truly innovative engagement; the attempt to take a creative idea (often as nebulous as a hunch) and turn it into a concrete deliverable that is invented as the project proceeds.
Across this spectrum are projects with various degrees of novelty. Some projects are trying new combination’s of elements that we know work well in isolation, and other projects extend the functionality of existing products in creative ways.
Related posts:
Pradeep Bhanot says:
This post applies well to software and building renovation projects. In an ideal world, one could do all the creative thinking prior to estimating effort. This would minimise the need for creativity when the task is underway, so schedules could be stable. In reality, both software developers and construction workers make estimates and pad them to give them some flexibility.
Software developers do this as the code they plan to write can create opportunities to rationalise or cleanup previous code, saving time. Or they can hit snags that make original estimates unrealistic.
In the construction world, imagine you are having some rotting decking replaced and the estimate sounds good before the work begins. Once you open up the top layer of wood, you can either find the rot is localised, so the estimate stands or it has reached extents that can only be seen after top layer is remove, which usually costly.
Pradeep Bhanot, Product Marketing Director, CA Clarity, CA