Do Requirements Really Change?

In my last post, I discussed change and how it is always present in projects. In this post I would like to discuss a particular area of change: what we often call changing requirements. Changing requirements are typically blamed for most ills in software projects. How can this be resolved with my earlier assertion that change is useful? We’ll give it a try.

I asserted earlier that one might consider embracing change. Get to know it better. Become intimate. So let us look at what is often meant by changing requirements.
(more…)

Dance of Change

In the Dance of Change by Senge, et. al., the authors present five disciplines for individuals and teams to study and practice that enable organizational learning. The disciplines are Personal Mastery, Mental Models, Shared Vision, Team Learning, and Systems Thinking. Today I thought it might be useful to explore one of these, Mental Models.

(more…)

When the Going Gets Tough, the Tough Use a Checklist

I know a pilot who has flown 7000 hours. The other day I asked him, “Chuck, the next time you fly are you going to use your pre-flight checklist?” “You bet!”, he replied. Now why would a jet pilot with that much experience use a checklist? . . . because that’s what professionals do. Professionals know that, in the heat of battle, much of our blood rushes to our arms and legs, where it is useful for hitting, kicking and running, leaving little to nourish the one major advantage that we have over monkeys—our frontal lobes. That’s why these common-sense principles are those that are most frequently overlooked or short-changed on projects, even by those who should know better. (more…)

RISK? What Could Possibly Go Wrong?

The most frequent mistake project teams make with regard to risk management, is an absolute kick in the head. The #1 mistake is to identify risks but do nothing about them. This is known as “documenting your demise.” Although people enthusiastically contribute to the long list of how the project team might meet with disaster, it is rare that they devote as much attention to tracking, avoiding, and mitigating these risks. Project risks are identified and tracked in a tidy document that never again sees the light of day. It is a completely predictable behavior. After all, the team barely has time to do the minimum required of them without addressing possible problems that MIGHT occur, but haven’t yet! Chances are, the risk list won’t be read again, once it is created – let alone used to drive decisions and behavior! (more…)

COMMUNICATION? We’ve Got REAL Work to Do!

Communication is pretty much the only means we have of leading effectively as project managers. While listening is a big part of that, when we DO speak, we need to find ways to be heard above the surrounding din. If you want your messages to get through the commotion surrounding most projects, keep it short, keep it relevant, keep it fun. Poor communication is yet another avoidable cause of project failure. Let’s wipe it out in our lifetime! (more…)

Responsibility Without Wiggle Room

Mediocre organizations are often plagued by the rampant abdication of responsibility of the very people who are supposed to be leading them. At every layer of management, these evasive characters somehow avoid committing to anything outside of their minuscule comfort zones. They fog their agreements with weasel-words that foreshadow their impending failure to deliver as promised. Adding to the confusion, the roles of team members are not clearly defined on many projects. Like a body without a head, the team lurches fitfully toward some hazy destination, unsure of who’s doing what. Most typical org charts don’t capture the complex relationships between people working on project teams. A Project Team Organization Chart can clarify who is leading the charge in each area. (more…)

Measurable Goals as Clear as Sunlight

Ignoring the needs of real customers is just the start. When most project teams hear the shot of the starting gun, they leap into figuring out HOW to do the project - before they clearly understand WHAT the project is intended to accomplish, and what is expected of them. When goals are fuzzy, instead of specific and measurable completion criteria, notions of the end result hover in a foggy haze where these clearly defined criteria should be. Each stakeholder will have a different idea of what defines success, and in which direction the finish line lies. Ask a group of people to draw a tree and each person will imagine and draw an entirely different tree. Similarly, when the goal of a project is not clearly specified, perception of the goal will vary from person to person, making shared goals a remote possibility. (more…)