The CIO Code

In my last post, I discussed the task of developing a promise and scrutinizing it. Part II deals with how to execute a promise and how to hold people accountable to the promise. When it comes to execution, the promise really comes down to this: this project will change over time; we are skilled in letting you know that something has changed; and we have the tools to help you adjust to the new circumstances.

Knowing that change will happen, the hardest part of managing a software project is often recognizing that a change has happened. It is so difficult to define a project carefully enough to recognize all of the details, that most often when something changes, it is invisible to all parties until the project goals are at risk. That is why so often the news of a late delivery comes late: something changed, no one said anything about it, and all of a sudden we are going to miss a deadline. This is also why models such as the Capability Maturity Model are so helpful at improving predictability. If we have a way to recognize change, we have a way of managing it.

Keeping a promise is more than project management, but project management is the key discipline to keep parties on a project aligned. I am a strong proponent of the Project Management Institute (PMI) Project Management Professional (PMP) certification, and insist that any project manager I work with is certified. We are aiming for predictability, after all, so it makes sense that project managers implement projects to a defined standard.

This is not a blog about project management, so I won’t delive into the details of each artifact of the PMI Body of Knowledge (PMBOK). However, I do want to highlight the deliverables and their objectives that have proven themselves useful at maintaining predictability.

In general, each of these artifacts is designed to: a) create a baseline of expectations; and b) manage the impact of changes to expectations. The artifacts I find especially helpful include:

• A Project Charter: this document defines an initiative so that we understand what we are trying to accomplish. The purpose of this document is to have a common reference point to the assumptions we made early in the project. Some of these are bound to change, and, if they do, the changes will need to be analyzed to determine if they have an impact on the project. Some of the details to capture are:
  • Objectives
  • Outcomes
  • Stakeholders
  • Sponsors
  • Budget
  • Time line
  • Risks
  • Constraints
• Project Plan: The purpose of this document is for people to understand the dependencies among tasks so that as change happens, we understand the implications. The purpose of this document is NOT to move bars on a Gantt chart from 0% to 100%. We know that change will happen over the course of a project. The tough part is knowing what happens to everything else if something new comes up.
• Requirements documentation: The requirements document captures the details of what we are going to build. The key challenge is producing documentation that is illuminating for all stakeholders. If it is too technical, you’ll lose the subject matter audience; if you make it too business-oriented, you’ll miss the technical implications of the system. The approach I have found to represent the best balance among these is one of Use Cases, which provide discrete, goal-oriented, tasks for the system. I’m sure I’ll get into this more somewhere else.
• Change management protocol: We know change is going to happen, so we need a way to raise changes and respond to them. We need to know who can provide the information to evaluate a change and we need to know the impact of the change on the whole project.
• Frequent cross-team meetings: I am a big fan of the Agile approach to daily standups, in which the entire team convenes for 15 minutes to assess risks and obstacles. The more frequently we discuss issues of substance, the more minor corrections we can make to the project to help it achieve its objectives.

There are countless other tools that can help baseline a project and manage change, but these represent some of the minimal artifacts and processes that work in any environment. Regardless of whether you are a developer or a sponsor, careful scrutiny of the tools used to manage change will be a strong indicator of project success.

As I mentioned in Part I, you need a good promise to execute from, but without the tools and discipline, the promise is only as good as the execution. You can be certain that when the promise is broken during execution, we are no less likely to be profoundly disappointed.

What tools have you found particularly useful? What have you found not to be useful?