PPM Perspectives

Innovation by Design

In an interview article with Tim Brown, CEO at Ideo, I came across a statement that caused me to stop reading and sit back in my chair. The interview question was about the process of innovation within an organization:

"Tim Brown: Even though companies want everyone to be thinking about innovation all the time, the reality is that everybody’s got other roles to play. So innovation is not a continuous activity; it’s a project-based activity. If you don’t have a process for choosing projects, starting projects, doing projects, and ending projects, you will never get very good at innovation. Projects need some form—you call them something; you run them in a certain way; you fund them in a certain way. That sounds simple, but, actually, a good process for getting projects going and done is often not obvious to companies."

Let me just spend a few more characters here and repeat one phrase: "innovation is not a continuous activity; it’s a project-based activity."

The quick background on Ideo is that they do new ideas. These guys noodle on everything from medicine delivery techniques to consumer products to childhood education. They are an idea laboratory. Their product is the new idea. They "create impact through design."

One might be tempted to look at this kind of innovation as a mysterious creative process, a process that cannot be clearly identified and that it is imbued with inscrutable shades of genius and black magic. Perhaps even a toad leg or two.

A confession: reading this statement felt like victory. When I started working on ways to create transparency in the project life cycle, I knew that one of the biggest objections would be the fear of stifling innovation. My response was always that we only stifle innovation in a transparent environment if we are not committed to invest in innovation in the first place. If innovation has to happen via secrecy and subterfuge, then what kind of organizations are we running?

As I have said "The future state of an organization is controlled by the people who lead it, and that future state is orchestrated via projects."

I'll let Tim Brown have the last word on why this stuff matters: "In the end, all businesses exist to serve some kind of human purpose. If you can’t somehow frame what you do in terms of having an impact on the world, I don’t see how you can have a very effective business."

by Demian Entrekin at ITToolbox

Dogmatic Slumbers

I was talking to one of IBM's Chief Engineer's, Landon Miller, about the religious wars that seem to flare up around "how to develop good software." I don't write often about software design and development methodologies, but if your projects require you to design and build your own software applications, then the relevance of this entry to your project leads should be straightforward.

The crux of our discussion was around the dogmatic battles between traditional software development models and agile approaches. The crux of the debate tends to revolve around the weaknesses of each approach. Rarely do the debates revolve around the strengths of each model.

In the traditional approach, the emphasis is on "documentation." In the agile approach, the emphasis falls on "working code."

The problem, say the agile zealots, with the traditional approach is that the teams get caught in a never-ending process of requirements gathering and paperwork and you end up creating a fantasy target that the team can't hit.

The problem, say the traditionalists, with the agile approach is that you just start coding and you have no fundamental architecture that will scale as your needs grow. You end up with spaghetti that has to be thrown away.

This "us and them" difference may seem a bit simplistic, but it's not all that far off from many conversations that I have found myself caught up in. You try to explain the value of documentation to an agile zealot and you are branded as quaint but dotty. You try to explain the value of agile to a traditionalist, and you are branded as a dangerous cowboy. I often find myself dancing in the DMZ of this one.

For once, right up front in our conversation, Landon and I both said that "this is a false choice." The best solution is a blend of both. Now, what he means by a blend and what I mean by a blend might not sync up when we hit the white board, but here's the point. The religious discussion is pointless and distracting.

Good leaders use the best of both (and whatever else they can use) to create a methodology that works. Even agile methodologies need to be written down and followed. Inculcate your teams in your methodology. Remain open-minded and change the approach as you go, but don't get caught in a pointless discussion that's based on dogmatic positions.

by Demian Entrekin

Tough Calls

There's just no getting around it. Right now, many of us need to focus our energies on making tough decisions. But it's not just about making tough decisions, it's about making the right decisions under tough conditions. If we can make solid decisions, even if the conditions have grown tougher and tighter, then perhaps they won't be quite so tough.

Some of us will continue to sermonize about process and visibility, which is all well and good, but we still need to make the tough calls. Do we fund this program and not that one? Do we shut this project down? Do we put that new product development project on hold or simply kill it?

With these thoughts running around in my addled brain, I was reading an article on Washington politics, and one quote in particular struck me. The article was about the role of the vice president, but the thrust of the quote was really about the flow of information. Walter Mondale points out that "the biggest single problem of our recent administration has been the failure of the President to be exposed to independent analysis not conditioned by what it is thought he wants to hear or often what others want him to hear."

Putting political positions aside, Modale's point is central to making decisions under tough conditions. In fact, I'd say that this perspective applies to making decisions under any conditions. The question of "independent analysis" goes to the heart of how organizations function or fail to function.

What makes "independent analysis" so important? Why do we care? From my perspective, this reflects on the way we think about information. It argues that we need to try to look at our situation from all sides before we make a decision. It means we realize that we all have biases that impact our ability to make good judgments.

In my experience, strong leaders go out of their way to encourage a broad understanding of the situation. Tough conditions do not destroy their ability to foster "independent analysis." Leaders guard against confirming their own biases. Leaders gather good information from multiple perspectives. Leaders facilitate objective evaluation.

So now what?

We can A) sit around and wait for the choices to hit us, or we can B) start preparing to make good decisions.

Since "A" is not an option, how do we do "B"? Objective analysis of good information is not a bad way to start. And by the way, these kinds of choices can revitalize an organization if handled correctly.

Demian Entrekin at ITToolbox

IT Governance in a Tough Economy

When survival is at stake, decision making tends to get clouded by knee-jerk reactions that often produce results opposite to what we want. "Retrench!" "Cut all new spending!"...
Maybe there is a way to say "No" that is better informed. I have seen good IT governance save many companies in 2000 and 2001 and I am seeing it re-surge again at this time of economic crisis.

The New Stuff Machine

New stuff arrives every day. This new stuff usually results from the determined efforts of a project team. In fact, a steady stream of new stuff comes from an army of project teams. But how often are we prepared for this new stuff? When we are not prepared, does that stop the new stuff from coming? Two letters: N O.

A CIO Perspective on PPM

Interview with the CIO of a major brand - discussing the role of IT; why PPM; why Innotas; who uses PPM and why; results; and lessons learned. Unfortunately the PR department of the company this CIO works for does not allow their employees to be featured in interviews so I had to omit all direct references to them. Other than that, the content of the interview has not been changed.

The quickest path to IT portfolio management

Why IT organizations need portfolio management? Because change happens and adjusting priorities and assessing the impact of changes is critical to the business and cannot be done on a spreadsheet. The question is: how hard is it to put portfolio management in place?

Where do you start with PPM?

Let's get practical. Leaving aside all the big discussions about objectives, alignment, executive sponsorship (don't get me wrong, these ARE important)...where do you start to get PPM done? Is there a pattern of implementation that is the most common across successful PPM implementations?

Resource management vs. resource scheduling

Human resources are the biggest expense in IT. So it's no wonder resource management is getting a lot of attention. Earlier today I asked Paul Ewry, an Innotas' consultants with years of PPM experience, what is the typical way in which he has seen companies determine if they have the resources they need for a project? He laughed: "Funny you should ask, in over 80% of the meetings in which I have asked that question, after a few moments of silence, somebody licks their finger and sticks it up in the air, followed by nervous laughter from everybody."  I'd love to hear other examples. But there has to be a better way.

Gantt Charts

I’ve been looking at Gantt chart functions and have been going round and round on whether Gantts need to be interactive or not, and if so how interactive. The main benefit provided by a Gantt chart is that it gives the people involved with a project an easily understandable visual representation of the project’s tasks over a timeline. It can be particularly useful when planning the project because you can see where the tasks fall on the calendar and you can see how the tasks relate to each other.