Project Management

The spectrum of innovation in IT project management

Rick Freedman explores the special characteristics of innovative IT projects. He discusses how projects fit into a broad spectrum of innovation and how project management oversight is applied.

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 combinations of elements that we know work well in isolation, and other projects extend the functionality of existing products in creative ways.

The various approaches to innovation

Assessing the degree of originality, and the associated risk and complexity, is one of the key analytical skills of mature project managers. Once the determination of innovativeness is made by the project manager, the prescription can vary greatly.

Some project managers, judging that a particularly innovative project brings with it hazy goals and additional risk, will be tempted to "clamp down," applying ever more rigorous and predictive management in the hope of mitigating risks. The downside of this approach is that, for the team that actually has to invent and deliver the product, this creates the wrong atmosphere. Writing a project plan for creativity is a doomed venture. "When will you be finished inventing?" is not a particularly useful question. The act of invention, and the unquantifiable human elements of creativity, is more likely to flourish in an open, collaborative, and unfettered environment, as proponents of agile methodologies have demonstrated.

On the other extreme, the most zealous of agile advocates will suggest minimal project oversight, sometimes proposing (as I've heard from a development team) that a weekly integration meeting is the only "ritual" that has any value, and that other project management activities are mere "ceremonies" to be avoided by truly creative programmers.

It's not just ardent agile-istas who prefer nominal project management; more often, it's the sponsors or project owners who question the value of project process and want to "get to the coding." In highly fluid markets in which customers' needs and desires change while the product is invented and created, some project sponsors see project management as an impediment to speed, rather than an enabler of purposeful invention.

The application of project management oversight

Experienced project managers know better. We understand that, from the most innovative and novel of projects to the most routine, it's not a question of whether project management oversight is applied but how it is applied. When you consider the innovative side of the spectrum, remember the following:

  • Creativity can't be planned, but it can be time-boxed. As an author, I know that I can't predict when I'll get an idea for a column or a book -- it usually happens at a most capricious moment, while I'm in the middle of something else, and my brain makes an unexpected connection. That doesn't mean, however, that I can't write on deadline. I know this column is due on Monday and, innovative or not, I'll muster the creativity necessary to produce a result. This analogy applies to writing software or designing a system; the freedom and space to think creatively is necessary, but a time-box sharpens the mind and ensures that, at some point, the brainstorming ends and the development of a tangible output begins.
  • Change happens. Dynamic markets and dynamic thinkers will result in changes as the project progresses. The project approach applied to innovative projects must have the capacity to enable, and even encourage, this dynamism or risk delivering the product that the market wanted when the project began last year and not the product that's needed now.
  • Innovation can be methodical. As R&D departments around the globe have learned, innovation is not confined to a "flash of genius," but instead is the result of strict, methodical procedures that can reliably create novel products. From new drugs to new consumer products like the iPod, innovation can be systematized, run as a project, and foster the creative freedom required while consistently delivering innovative results.

Next week, I'll dig deeper into the methods that project managers apply to walk the fine line between creativity and routine and between control and chaos.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!


Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...


I have worked in both kinds of environments - free-for-all Agile cowboy coders and strict RUP shops, and many shades of gray in between. When I come across a project that is basically new product development, I call it out. I make a big deal that it is NOT a simple install & config project as everyone may have initially thought. The new "product" (think flexibly here) that could need development might be a business process in addition to the technical piece. Doing one without the other is a disaster waiting to happen. There could be an organizational change component that needs to be realized and implemented in addition to the technical piece. If the technical work includes doing things that have never been done before, there needs to be room to experiment and the freedom to not know something until it's been tried. SOMETIMES the documentation can't be done in advance as a predictive design step. SOMETIMES it has to be done after the fact as a knowledge capture step. If the PM doesn't know the difference, and call out the places where the experimental work is happening, the team may have undue pressure put on them to provide pre-defned results in a pre-defined time frame. Out of fairness, and so management doesn't think the project is a never ending spiral toward a black hole of doom, provide info on the time boxes, deadlines, and checkpoints/gates. Put in estimated hours on the work that can be estimated. If it can't be estimated, then don't fall into the rookie trap of making up an "estimate" hoping nobody will catch on it's really a timebox. You'll pay for that later and you're misleading your stakeholders. It can be enormously frustrating to work with team members and management who want everything to be known on day 1 at a very atomic level of detail, planned against a stop-watch, and to see the plan in concrete every morning, as if it's Mount Rushmore. I feel I have a professional responsibility to give these folks the right information to help them make the best decision possible, even if they aren't comfortable with it. Doing otherwise feels like a sham.

Editor's Picks