Reflecting upon my experiences with process management and process improvement initiatives, I’ve recently come to notice a glaring problem that I and many others have been guilty of perpetuating – we often have a lack of regard for what we consider a tool and what is considered a deliverable.
These are two different things but for some reason often end up in the same column. Here’s an example that actually happened to me at some point. As most of us know, risk management is a critical component of most process frameworks like CMMI and ISO. As we tried to get certifications for these frameworks, it soon became mandatory for project leaders and managers to create risk management sheets, have them approved by someone, and “release” them as one would with technical documentation or software code.
Come to think of it, I don’t know if anyone ever read or used those sheets, except come audit time. Faced with deadlines for these “deliverables”, I tended to put the bare minimum, almost templated content in these sheets. All of that considered, it’s pretty clear those sheets ended up with no value at all to me nor to anyone else.
On the other hand, if I had looked at those sheets as a tool (instead of just something I needed to submit) and better understood how they could be helpful in planning for the worst case, things might have ended up so much differently.
So what’s the difference?
To start with, a process in itself is a communication and value creation tool (note, not a deliverable). The actual deliverable of processes is whatever actually has value to the “customer” (or whoever is next in line on the value chain). Anything that helps you produce that value is, on the other hand, a tool.
Ultimately, a software engineering team’s output is software. Of course, a lot of collaterals come with it – user manuals, technical documentation, release notes, and whatnot. These are important output, too, as they are valuable for customers to use our software effectively as well as for future developers to maintain them the right way.
Project management, in general, is an internal process. It’s how we deliver, as opposed to what. In line with that, things like a risk management sheet are definitely not what I would consider a deliverable. Customers don’t care how much trouble we were almost in trying to deliver their software. They just want the software and they want it on time and with quality.
A risk management sheet, when used right, allows us to deliver software the right way. We fill it in to organize our thoughts, take a look at it once in a while to make sure we’re on track, and we update it so we don’t forget where we are at. Now that’s value, albeit not to the customers. That’s a tool.
Why does it even matter?
If you’re going to be output-oriented, it’s important to know and be selective about what your output really is. That’s your finish line and you want all your next steps to move towards that.
In my experience, the mindset towards delivering work can shift dramatically based on how the value of it is perceived. If you can’t imagine how the output of your work becomes valuable to the customer, you probably won’t be very motivated to work on it. If you consider it a tool for your own use, on the other hand, you’ll be driven to find how to make it work for you – or decide to drop it altogether (not a bad option in many cases, to be honest).
Simply put, considering tools as deliverables often leads to meaningless work or work for the sake of compliance. Neither one is a good use of time.
Understanding the value of work
Whenever you have a list of deliverables you need to release in your project timeline, always ask the question first – how does this help our customers (both internal and external)? If you can’t find an answer, you should think twice about its value.
In the end, that’s really all it’s about. Deliverables and tools are both valuable, but in very different ways. Understanding how and to whom certain things are valuable enables us to use them the right way or not use them at all.
While the road towards the finish line is important, there’s often more than one road you can take and different folks will have different preferences. In the case of a software project, picking the right tools is basically choosing your road. But the finish line is always where the reward awaits.
Here’s a quick challenge – think of all the things you expect from your team as “deliverables”. Try to find out if they actually are deliverables or should be thought of as tools. Improving your team’s motivation could be a matter of setting the right expectations as to what things they are doing should be considered a tool and empowering them to make decisions on whether these tools serve their purpose or if something better can be done.