Success with Requirement Gathering – a Citrix Workspace example
When was the last time your project went completely off the rails? Behind schedule, well over budget, unhappy client, low morale project team, and an exhausted project manager.
Last week I had the privilege of spending time with friends and partners at Citrix Summit 2020. Here we began to dig into the exciting advancements made to Citrix Workspace and the intelligence behind it that is designed to enhance user experience, productivity, and security.
I had to take a pause during the excitement and consider what this might look like as an implementation project. Could this project get behind schedule, go over budget or outright fail – of course – it’s no different than any other project. BUT it doesn’t need to be.
The excitement for me as an end user with Citrix Workspace comes from the customizable experience of work that is important to my day. So many amazing features, functions, workflows, alerts, suggestions, I could go on; maybe another blog. However, what we need to focus on is the term “customizable experience”.
As a project manager, “customizable experience” in sales-speak means “requirement gathering” in project-speak. In my humble opinion requirements gathering is the cornerstone for project success in any industry, any technology. Botch this part up, and your chance of success diminishes rapidly. Continuing my Citrix Workspace example, this means that realizing all the amazing benefits from Citrix Workspace necessitates comprehensive requirements gathering, including end-user interaction/usage requirements (as with most technologies).
According to the annual Chaos Report published by the Standish Group, in the US alone there are approximately 175,000 IT projects inflight with a combined budget of $250 billion.
· 31.1% will be canceled
· 52.7% will end up costing 189% of the original budget
· Only 16.2% will be completed on-time and on-budget
The Chaos Report goes on to say the top 3 reasons for project failure are as follows:
· Lack of User Input – 12.8%
· Incomplete Requirements and Specifications – 12.3%
· Changing Requirements and Specifications – 11.8%
Almost 37% of all failed IT projects have nothing to do with the technology and everything to do with users and their requirements.
Our requirements gathering phase of a project and its output is critical for not only quality project execution, but quality scoping in the beginning, and quality pricing. After all, how can you possibly put a price tag to something you have not fully discovered, documented, and agreed upon with a client?
Besides the development of the technical requirements, have you considered all the business requirements?
The following discovery activities will significantly influence project duration (and thus price):
· Have you gone through the application rationalization exercise with your client?
· Do you know who owns the applications, their contact information, their assigned testers? Have you reviewed their test plans?
· Was a complete user profile discovery documented?
· Do we know the repetitive tasks that need automating?
· Are we familiar with some of their more mundane workflows that could be streamlined?
All this to say that attention needs to be given to the gathering of our end user requirements to ensure success. Remember a project is still considered a failure if it comes in on time, at budget, but is not returning the positive experience the client was expecting and therefore not being used.
While I have had the privilege of working on many of these types of projects with this activity being second nature to my team, there are others who are unfamiliar with the importance of this step. Project managers need to sometimes “negotiate” their way into the engagement scoping and quoting exercises with the Sales team to ensure requirements are gathered correctly for successful implementations; but once proven with a client, you will be invited back to the pre-sales table time and again.
Any project with complexities, customizations, regulatory restrictions, and/or high numbers of various end users’ needs to be treated extra carefully to ensure both parties know exactly what project success looks like.
As we have heard before, if you have three hours to chop down a large tree, take the first two hours to properly sharpen the ax. Gathering requirements up front is no different, it awards us the smooth execution after our careful planning. We slow down to go fast.