I’ve been working on a program that has certain been a challenge, both from the subject matter, the extremely short timeframes given (imposed governmental regulations that must be met), to the stakeholders (who have day jobs to perform as well). Everyone is under pressure, which can make for some short fuses as well as poor decisions.
While this program is still in progress, we already have several lessons learned, and try to implement corrections and improvements for the later phases of the program. One of those lessons learned is sticking to my guns when it comes to the defined process for requirements elicitation.
At ArgonDigital, we do have a defined process for elicitation and documentation of requirements for our project work. For my program, I made some adjustments due to the nature of the project and other constraints (something that I feel that we should always do, not every project is the same and some customization may be required). As part of our kick off presentations, we introduced the requirements process to our stakeholders and subject matter experts, along with several reasons why we use the process and the value that it adds.
Well, as I’m sure you have already guessed by the title of this blog, things did not go as planned. We met a lot of resistance to our process, which is different than what the stakeholders were used to following. They were used to dictating their requirements to a business analyst, who dutifully wrote down everything that was told to them, ensured the formatting was proper, and turned the document back around for approvals. Try as I might, with every which way but loose for explaining why we wanted to do something as simple as process flows, I was unsuccessful for the most part. After advocating and urging for our process to be followed, I eventually caved and gave up. Ugh.
Fast forward to the end of some of the first requirements documents for this program. The documents are high level, and are now being viewed as not totally complete, and missing information. And unfortunately, I’m not surprised. Because we were not able to follow our standard process, which helps ensure that we look at the domain from several different perspectives, as well as learn the domain, of course there are holes and missing information. Even our sponsor has admitted that they would not let us follow our defined process, and the results were less than desired.
I wish I could say “told you so”, but that is neither helpful nor professional. We are only part way through this program, my challenge now is to learn from the past to try and improve the future. Our project sponsor seems to be on board, we have to stick to our processes moving forward. Yet I fear more resistance headed my way. I’ll need to find a way to convince folks that our process works, and it works really well.
The biggest lesson for me so far is another reminder on just how well the ArgonDigital process works. I know it does, since I’ve been using it on projects for years. However, sometimes efforts like these, where we don’t follow what we know is the best way to do things and the poor requirements that result, serve as a terrific reminder. And a reminder to stick to our guns.
