In Part 1 of this series I wrote about what happens when a rogue team member starts work on a project before all of the detailed requirements are in place. While not always catastrophic, this practice can lead to some negative issues placing the project in jeopardy from a budget, timeline and/or customer satisfaction standpoint.
In this article, I will examine the other side of the issue – when the work knowingly moves forward without enough time given to the requirements and business process definition activities.
Defining Today
Before a new (replacement) process or system can be put into place in an organization, it is critical for the current processes to be adequately mapped out. Why? Because if this activity does not happen, or does not happen in enough detail, then the new/replacement system may not fulfill all of the needs of the organization resulting in a system that is essentially an expensive door-stop.
Before an engagement starts, it’s imperative that the customer know what their current business processes are and have an idea of what they need to be. Too many customers like to ‘wing it’ heading into an IT project thinking that they truly know their business processes inside and out when they actually don’t.
I’ve had several projects where we get into the Exploration phase and discuss the current business processes against the ‘to be’ processes only to find out that the customer really doesn’t know what currently happens and doesn’t know for sure what they’re trying to replace with the new solution. What then happens is frightening.
At this point, the customer realizes that they aren’t as prepared for the engagement as they thought they were and they realize that both the timeline and the budget are in jeopardy already during Phase 2 of the project. Usually, they want to blame Sales for not properly preparing and informing them, but ultimately the customer should know their business better. They need to take the time and engage the proper subject matter experts (SMEs) to help define processes and identify key areas that need to be addressed by the incoming software solution.
Get It Right The First Time
It’s no secret that getting the requirements well documented up front can tremendously decrease work on the development side. This includes re-work due to requirements change, fewer change orders and therefore less cost to the customer, and reduced testing effort. It’s critical that the Project Manager ensure that enough time is built into the schedule to cover business process review, gap analysis, Business Requirements Document (BRD) creation and review, Functional Design Document (FDD) creation and review, and Technical Design Document (TDD) creation and review. Extra time spent on these tasks will make the development effort exponentially easier.
In Conclusion
To sum it up, as the PM on a project we need to be sure that we’ve allocated the right window of effort to the prep tasks. The customer needs to see a thorough amount of time spent on the “R” tasks defining the processes and requirements so that they are confident we can deliver on the “D” tasks. Fewer change orders will result. While this may initially be bad for short-term revenue it is overall very good for customer retention and word-of-mouth goodwill. And it is definitely good for ultimate project success.