Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The Meaning of Rigor in Project Management

October 27th, 2007 · 7 Comments

Rigor is a popular topic among IT project managers, often used in the context of describing how a PM should adhere to a particular process. It’s been on my mind quite a bit lately, and I’ve made some conclusions about what “rigor” means to me, as project managers who use agile are frequently criticized as not being particularly rigorous.

First, let’s start with Webster.

(1): harsh inflexibility in opinion, temper, or judgment : severity
(2): the quality of being unyielding or inflexible : strictness
(3): severity of life : austerity b: an act or instance of strictness, severity, or cruelty 2: a tremor caused by a chill 3: a condition that makes life difficult, challenging, or uncomfortable; especially : extremity of cold
(4): strict precision : exactness

Not very cheery, if you ask me, but let’s talk about how it’s used. Typical usage with regard to project management my frequently feel like (1) above (harsh inflexibility in opinion, temper, or judgment), but that’s not what we typically mean when we talk about rigor in project management.

Instead, it typically means the strict precision with which you follow some project management belief or practice. For many PM’s, it means the strict precision with which you follow the process. I have tried, over the years, to have this type of rigor, but I usually fail, while my projects usually succeed. Project management ideals always get supplanted by the expediency of execution on my projects, whether I am using waterfall, iterative, or even Agile.

Let me give you some examples of my shortcomings in project management rigor, at least in the sense of process adherence:

  • I can’t stick to “phases”. My projects start testing almost as soon as we start coding, or we start design as soon as we have a few requirements. I rarely wait for one phase to finish before I start the next.
  • We don’t stand up at my Agile standups. Does this waste time? Yes – my standups usually include several minutes of friendly jawing.
  • I don’t resist scope/requirement changes, even in a change-controlled environment.
  • I don’t typically create contracts between IT and the business.
  • I don’t define roles & responsibilities in clear, rigid ways.
  • Project team members aren’t required to produce formal status reports.
  • Formal documents, like test plans, communication plans, and yes, even project plans, don’t have a significant role on my projects.
  • This list could go on and on. Some of my colleagues could add it to it considerably based on their observations of me, and rightly so. I am not really devoted enough to any one methodology to apply “strict precision” to following the process.

    Now for the irony. I’m a reasonably successful project manager. I’m batting well over .500 on project delivery. How can I be successful without process rigor? Shouldn’t I be failing more than I succeed? There are plenty of PM’s out there with process rigor with lower batting averages, of that I’m sure. I think the answer lies in the type of rigor I do have.

    So, here’s what I’m rigorous about. Here are the things I apply strict precision to.

  • Telling the truth about my projects.
  • Eliminating ALL activities that don’t contribute to the delivery of valuable working software.
  • Creating achievable commitments to deliver.
  • Managing focus of a project team.
  • Understanding and fulfilling the needs of the business.
  • Creating an environment that optimizes the ability of project team members to contribute.
  • Your chances of creating project success are not defined by the strict precision with which you follow a process. I would argue that the factors I’ve described have a substantially greater impact on whether a project succeeds or fails than whether you stand up at standups or complete one phase before you start another.

    This is my rigor. Obviously, someone who is rigorous in this way, but doesn’t follow a process with strict precision, is going to have perception problems, especially if they insist on being honest about their projects, as I foolishly do. Here is what you can expect others to say about you:

  • You only do the minimum required to get by.
  • Your projects are disorganized.
  • It’s hard to see who does what and when.
  • Where’s the effing project plan?(not the same thing as a schedule, BTW)
  • How can you write software without detailed requirements? I like this one, I have to bite my tongue to not say something like “Look who’s talking. You can’t even write software WITH detailed requirements!” depending on who says it.
  • This list could be never ending as well. The truth is, my rigor, without process rigor, invites political and social trouble, even if it doesn’t hurt project delivery. I am envious of people with both types of rigor, especially if it comes naturally to them. They are the golden stars and starlets of the PM world – loved by the business and by IT management. Likewise, I’m disgusted with people who have only process rigor. They are hated by their business partners and baffling to IT management. I wouldn’t want to be that sort of PM no matter what. Fortunately, they don’t last very long.

    As a PM who lacks process rigor, I have developed a few “workarounds” to help keep me out of trouble. I’m going to share those workarounds in the hope that I’m not the only one who struggles to be “process rigorous.” Here they are:

  • Keep a list of “hot water” activities. These are the parts of the process that get IT management riled up when they aren’t done properly. Project financials and status reporting frequently fall into this category.
  • Focus on doing the “hot water” activities VERY well.
  • Keep a list of minimum “must do” activities. These are activities that must be completed to finish a project, like documenting certain things, having a review, etc.
  • Focus on doing the “must do” activities well enough. Don’t put more energy into them than is needed to get a pass.
  • Keep a list of activities that are required on paper but not in practice. Don’t do them unless you think they will add value to your project.
  • For me, these lists are in my head and they grow and shrink by trial and error. They also need to be tailored for the particular managers you are dealing with. One manager’s “hot water” activities aren’t necessarily the same as another’s. When you get yelled at for not having this or that, adjust your list.

    Process rigor doesn’t have a correlation with project success, and ultimately project managers who don’t deliver successful projects won’t make it. You need to have another kind of rigor as well, a rigor I call “project rigor”. If you haven’t got it, you’d better get it. You won’t get there without it.

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Project Management

    7 responses so far ↓

    • 1 Anonymous // Oct 29, 2007 at 2:28 pm

      Great post. Lots of courage.

    • 2 Srirangan // Nov 12, 2007 at 1:58 am

      Thanks for the post, was very interesting. I could relate a lot of what was said to the things happening around me.

      – Sri

    • 3 123 // Nov 6, 2009 at 3:12 pm

      Dude, you GET IT!!! The problem we are facing with our new IT manager is that all he knows in agile, and he can't see the forrest for the trees (translation: see the project for the process). Only a fraction of our projects are application related, the rest are on a college campus scale (coordinating furniture locations, upgrading computers systems, inventory control, capacity planning, etc)

    • 4 SuhasYN // Nov 18, 2009 at 1:01 pm

      Good one ,can be helpful for the PM's

    • 5 Inez // Feb 10, 2011 at 1:14 am

      This is reality…very pragmatic..Process people should learn from this and do a better job.

    • 6 Dianna Knight // Sep 29, 2011 at 3:19 pm

      Hi David –

      Just read this post (while looking for more “official” project rigor info).

      Very funny, very applicable and probably would be considered slightly subversive at my job – but I still might share it with my colleagues!

      Thx for posting (all the way back in ’07).

      Hope you are well these days :)

      – D

    • 7 Caesar Padilla // Jun 21, 2013 at 10:48 am

      You are right on the money. Many organizations go to the extend of creating complex and rather convoluted processes of calcualting a project rigour with extensive documentation attached to it which eventually has to be reviewed and approved by the product owner.
      What a waste of time!

    Leave a Comment