I saw a license plate recently that read DWYSYWD. I puzzled over it for a while (Google wasn’t handy), and then it suddenly flashed on me: Do What You Say You Will Do. I’ve since learned that this is a well-known phrase, used by people such as Colin Powell, among others.
How does this relate to IT and the CTO/CIO? Well, all sermonizing aside about how “Do What You Say You Will Do” is a great mantra in general for life, it particularly fits the rapidly swirling technical project world that the CTO/CIO copes with every day. In that world, as we all know, it’s easy to say that you’ll do things, and you’ll certainly be pressured to say you’ll do more and more. Actually getting them done, however, is a bit harder.
How important is it to Do What You Say You Will Do? I went into a CTO role once where I rapidly observed that I had inherited a team that wasn’t doing. In fact, the team wasn’t saying, either. Astonishing as it may seem, they had been allowed by company management to fall into the pattern of making no commitments for delivery, in anything other than the vaguest of possible terms, most of which had to do with stating noble intentions of working hard. In other words, they weren’t really putting themselves on the line. A major part of my approach there was to emphasize the importance of making, and then meeting, specific commitments for delivery. “Commit, Deliver, Track & Communicate” became the simply-stated, three-pronged “get well plan” in that situation. Easily stated, not so easy to achieve; but that’s a story for a different posting someday.
My major point here, though, and an important part of project delivery (doing what you say you will do) that occasionally gets lost, is declaring victory when the project is successfully launched. This declaration should be a relatively formal, executive-penned announcement of the launch, usually delivered via a broadly disseminated e-mail.
Insisting on declaring victory has a number of important purposes:
- Declaring victory provides a transition point. You’ve moved out of the initial delivery into the sustainment phase for this system, meaning that the way that stakeholders interact with the team (and often the very team itself) will be different.
- Declaring victory lets you recognize the team’s accomplishment, collectively and also for specific key contributors, inside and outside of IT. It gives you a forum to recognize the collaboration you’ve had with the stakeholders, and to applaud their hard work and patience.
- Declaring victory, when in the context of an ongoing “Do What You Say You Will Do” project portfolio management philosophy, builds confidence that victory is indeed what’s happening, in the grand picture. It underscores that you’ve committed, delivered, and can now move on to the many other projects in your queue.
- Having to go through the actual step of declaring victory forces the team itself to self-scrutinize: are we in fact really done? Have we met the criteria for success? Do our stakeholders themselves believe that we’re done, or is it just wishful thinking on our part?
- The text of the declaration itself should remind people of what the project actually does, at a high level, and (sometimes) what it does not do. This is one last place where you can restate the project’s goals, accomplishments, and benefits for the company. It’s a great place to point people to sources of deeper information (functional requirements specifications, etc.)
Declarations of victory need to be widespread, published to all stakeholders that you deal with, not just limited to the project stakeholders. Remember that you’re operating in a project portfolio management mode, where all activities you engage in represent opportunity costs against other conceivable work/projects. Telling the Finance team that you just delivered a major project for the Tech Support side of the company may seem like a relatively meaningless step, but it actually helps everyone start to realize that it’s not just about them. These lessons come slowly, and often hard.
As Supreme Court Chief Justice Roberts recently said, “one of the most famous umpires in major league baseball history, Bill Klem, was once asked, ‘Was that a ball or a strike,’ and he said, ‘You know, it’s not a ball or a strike until I say it is.'” To the extent possible, be your own umpire. For your projects to be considered successful, make sure that you don’t omit the key step of declaring victory.
‘You know, it’s not a ball or a strike until I say it is.’
The Uncertainty Principle of Baseball.
I’ve been thinking about this since I wrote it. I should have more broadly stated that the major criterion for victory is that the USERS consider it to be such. My point, though, was that even if the users think it, until you actually declare the victory, it’s almost like that victory doesn’t really exist.
But yes, I do like the baseball analogies.