Edward KleinertClinical Assistant Professor| New York UniversityNew York, Ny, United States
Mike...We like your 'Joke Alert'...
...And of course, your take and Andy's, on the importance of requirements tractability for all projects. It serves a ‘practical’ need in the planning, execution, and management of a project. But it also serves an important ‘communications’ need for the project stakeholders. It is a demonstration that our commitment of translating the vision to the solution is real. And that we really take seriously, the importance of requirements management, starting with what the customer needs and why it is important. It helps to ensure proof of compliance and visibility at every stage of the project.
Saving Changes...
Edward KleinertClinical Assistant Professor| New York UniversityNew York, Ny, United States
The foundation of a project is based on a business need... A problem that requires a solution, or an opportunity, that if taken advantage of, may improve an organizations position, or a new directive (law, rule, or regulation) that must be complied with. This fundamental principle needs to be discovered, articulated, verified, and validated to make the business case for proceeding.
Now that the stage has been set…why do organizations struggle to realize the promise of a project…? Recent research, conducted by PMI in 2014, indicated that only two-thirds of all projects met their original goals and intent. And that 37% of the participating organizations reported ‘inaccurate requirements gathering’ as the primary cause of project failure.
Why does this happen? What are the reasons that contribute to the challenge of determining what is needed, to a level of specificity, that ensures a common and agreed to understanding ( across stakeholders,) to enable a team to deliver to the promise…?
If this question feels all too obvious…you’re right. It is fundamental to the understanding of the promise of project management. And it all begins with the initiation of an idea…
What are your thoughts and opinions…? Share the reality of your experience…
Saving Changes...
Mike FrenetteManager, IT PMO| Halifax Water (retired)Halifax, Nova Scotia, Canada
"Why does this happen? What are the reasons that contribute to the challenge…? "
Have you ever engaged in that party game of whispering from one person to another something that originated on the other side of the room only to find it is totally unrecognizable by the time the last person repeats it? Sometimes the results are hilarious.
Sadly, though, hilarity is not normally the result when similar things happen on projects.
When we make assumptions about what we've heard, when we design, develop, construct in the absence of confirmation of requirements, we have only ourselves to blame when the result is not the simple rope swing the client wanted (citing the 30 or 40 year-old diagram I'm sure everyone has seen that ends with "what the client wanted" and is preceded by many ridiculous permutations of what various people involved in the project envisioned).
So - lack of clarity and lack of confirmation are both reasons we can get it so wrong. So what to do? The processes and modeling methods outlined in many texts and articles, including of course PMI's recent "Business Analysis for Practitioners: A Practice Guide", are one way to do it. These add methods add visuals to the mix to make it much more difficult to misinterpret requirements.
But there are other reasons we get it wrong. Speaking different languages is one. Are you fluent in Analyst? Architect? Designer? Developer? Tester? And how about Business? If not you'd better find someone who speaks more than one when it comes time to transition from one language to the next - those moves from analysis to design to development to testing to implementation, even if only for a single user story in an Agile environment. Models help with this too, but anyone who has seen a complex architectural diagram with all its data, processes, interfaces, hardware, network and so on in an IT-related project will know that the road of translation from business to architect/designer is filled with potholes, sink holes and even land mines. :)
And of course (dare I say it?), the premise is always that clients know what they want.
Consider what might have happened if we asked a horse and buggy owner what they would like in an automobile, or the wired and dialed telephone user (if anyone remembers those days) what they want in a mobile telephone (if we can still call these amazing tiny powerful computers we carry around in our pockets telephones), or today's electronic device users what they might like to have "in the cloud", or even today's business how they would like to use massive amounts of data to improve their business goals.
But, I have stretched this out far too long. I hope that, at least, it is entertaining.
My point, in short, is that clients often don't know what they want and need until they see what they can have, until the world of possibilities comes into a clearer focus with the help of models, prototypes, and unfortunately, sometimes the end product. And there are many translational hurdles along the way as we transition from on specialty to another.
I'm sure there are many other reasons. Hopefully others will post them here. Saving Changes...
