Preface: In a perfect world, key elements like project requirements and execution steps would be issued by a product owner or PM. But the real world is imperfect. What do you do when you find yourself sitting by the side of the road with a flat tire and a bleeding head, reading a manual that suggests you wear a helmet? Such a “best practice” is not very helpful when you’re in the thick of things. This post is written for an imperfect world. I’ll share what I do when reality happens—when I’m floundering for adequate direction, prioritization, or structure.
Here is how, from the chaos of tasks and daily priorities, order is born.
Recently, I found myself simultaneously working on 4 different IT projects (an upgrade, an infrastructure move, and 2 evaluations). Each day, I performed little tasks to move the projects forward, but each time I returned to my desk I kept thinking, “Is this the most important thing to do right now? How close am I to the final goal? Where am I on the map of project progress?” I needed a compass.
The solution I developed took the form of 3 simple lists: Requirements, Issues, and Execution Steps. Let’s explore each in detail.
1. Requirements List
There is often an enormous gap between the tasks we are asked to perform and actual project requirements. Translating each task into a requirement allows me to go back and ask the tough question: ask not what you need to do, but what your project is trying to achieve?
Here are some examples:
[table id=14 /]
Shift your thinking from features or characteristics to the intention behind the task—the why. (But avoid getting into the details of how the requirement will be satisfied.) A good requirements list for any project becomes a guiding light for your decisions around priorities and resources.
2. Issues List
Every time you run into a small side problem – record it! It’s that simple. You’re turning a web of messy problems into a neat, sortable stack. The trick is speed. If recording a problem turns into a complex procedure of its own, this won’t work. People won’t use such a system, and most of the problems will be swept under the rug. The web of problems will only thicken.
The most primitive Issues list will include:
1) Date Recorded
2) Issue Description
5) Date Last Updated
6) Additional Notes
* Don’t get too extravagant with the status field. When an issue gets recorded it can start with OPEN or TIME NEEDED, meaning you’re just adding one more “tile to the pile” for future consideration. As issues nudge toward resolution, I find it useful to have an IN TESTING status, meaning a solution was found and implemented, but we do not know if it will resolve the problem. On large projects, the implementation of a solution and testing can be separated by weeks. When you CLOSE an issue, you’ll have a record what happened and what was done to resolve it. This feature of an Issues list is often overlooked, but it is the gift that keeps on giving.
When collaborating with others, add:
7) Reported By
8) Assigned To
9) Date Promised
If you extend your Issues list to an even larger audience, you’ll need a more robust tool; Excel will no longer work. Yes, to be successful with your project you will need to spend money to track issues. It may sound obvious, but for some reason this is not apparent among some project teams. The number of fields will grow again. Now you’ll need to track status by team and priority level.
One pitfall to be aware of is that the number of fields do have a tendency to get out of control. At some point, the number of required columns makes this tool not user-friendly. Fight uncontrollable growth of fields and columns by clearly defining each column’s purpose.
3. Execution Steps, a.k.a. Roadmap
The first time around, when there are too many unknowns, it is OK to improvise while you are searching for solutions. But do not let this happened to you on the second and third and every additional round of a project. To avoid finding yourself in this situation, create a step-by-step project execution plan early on.
Steps in an Execution Plan should be numbered. It should have a brief description and space for more details. If related information is needed, use a separate sheet or add a link to a site with additional instructions. This document should read as a list, but do not skimp on crucial technical details. Include columns for Assigned To, Activity Type, and Department. Also try to capture average duration of the step.
This document is never fully complete until the actual Go-Live date, but when teams work on this document, they are charting their course, and learning how other teams contribute to the project. Understanding your place on a project map relative to other teams and tasks is critical to building morale and confidence in project success.
On very long projects, there is a higher probability that not all team members will last for as long a project does. When team members leave, the Execution Plan becomes invaluable. Try to capture steps, technicalities, dependencies, and rationales behind the steps so your road map is the ultimate source of accumulated project knowledge.
Summary: 3 Lists for Any IT Project
For clear goals and measurable success criteria, create and maintain a project Requirements list.
To focus on a current problem, and to unravel a confusing web of small surrounding issues, maintain a simple Issues list.
To safeguard yourself from reinventing the wheel, losing knowhow, and overlooking dependencies, create and maintain a list of Execution Steps.