One of our standard mantras here at Kelcey &Co.: it all starts with good requirements.
For almost every project that we take on, we follow a classical Systems Engineering approach where we spend a significant part of the early project defining the requirements, otherwise known as “what this process/tool/database is supposed to do.” Failure to follow this process almost always leads to insufficient outcomes and unhappy stakeholders.
So why doesn’t everyone do this?
Well, first off, there is hubris (I know–stones and glass houses!). It is easy to begin seemingly small projects by saying “I know what I want and I can figure out what I need to design, build, or ask a developer to create without ‘wasting time’ planning and documenting requirements.” But statistics show that an overwhelming number of projects fail this way.
Other (unacceptable) reasons include:
– Time perceptions (“We don’t have time to get the requirements done.” But you will find the time to fix the mistakes?)
– Unawareness (“I didn’t know that I should have written requirements.”)
So what does this mean for you?
Even if you can only take a single project hour to do so, document your requirements and share them with the stakeholders. This will give them an opportunity to say “why does the system/project/process need to do that?” Or conversely, point out missing requirements. You will have saved yourself a chunk of rework in the future and taken some potential disappointment off the table.
Want some guidance in how to create great requirements and implement solid project planning and management? Kelcey & Co. is the requirement that can make that happen for you.