If You Don’t Know Where You’re Going ANY Road Will Take You There!
Lilly Tomlin once said “When I was young I always wanted to BE somebody when I grew up. I just wish I’d been more specific.” Isn’t THAT the truth! Many project teams hear the shot of the starting gun and leap into figuring out HOW they will do the project before they even understand clearly WHAT the heck project is intended to accomplish. Customers? Ha! An afterthought at best. Ignoring the needs of real customers is just the start. Goals are unclear. Nebulous and ill-defined notions of the end game hover in a foggy haze where specific and measurable completion criteria should be. Each stakeholder has a different idea of what defines success and in which direction the finish line lies. Like a group of school children whose teacher asks each one to draw a tree, each imagines and begins creating an entirely different tree. As different as a bonsai and a sequoia, the goal of the project varies widely from person to person. The project manager must create a grand unified vision of success (sorry, the physicist in me leaks out once in a while!), what it looks like, feels like, sounds like, tastes like and smells like. Every single person associated with the project must share a similar hallucination about the end result to which the team is committed in order to make all due speed toward that common goal. If you can’t be done you sure as heck won’t know when you are. No wonder scope creep has turned into scope LEAP in the past decade!! Your thoughts?
I think, most of the time we sort of know what we want, but, not sure how to go about to get that(which road to take).
I agree with what you say ‘If You Don’t Know Where You’re Going ANY Road Will Take You There’. It all boils down to the basic temperament of the individuals. Some people have a burning desire to achieve and most of the time they know how to get what they want. Some are happy with whatever life has to offer & they are not much bothered about which road they take as long as it takes care of the basic needs.
Reply
Requirements engineering is my hot-button topic, and you’ve pushed it. I consider requirements capture to be the most critical part of any development. When requirements aren’t properly identified, the developed product won’t meet the needs of the client or the expectations of management. If the development team does not understand the requirements, sufficient resources won’t be allocated to the project, and the product will be late. Failures in budget, schedule, and usability can all be traced back to poorly stated (or not documented) requirements.
Reply
Not too long ago, just after I had joined a company a “Project Manager” was helping manage the relationship with the offshore team (which was new and on its very first project with the company). I sat in their first status check meeting as the VP of Engineering (along with my Director of Engineering and Products). The “Project Manager” was actually quite qualified and knew all the right words. She wanted status, risks/issues, mitigation strategy etc.
The key member of the offshore team in house that week and the rest of the team was on the phone. I heard a long silence at all ends when the project manager repeated “but when can we get the project plan”….and then someone said but we need time to figure things out before we make a plan and commit to a date.
A little irritated I said “figure what things out? you have been at this for 2 weeks already. Take a look at the requirements doc, ask for clarification on things you don’t understand, figure out feasibility of implementing the request and then make your plan. How long does it take? This is not rocket science” There was complete silence and then someone said that the requirements came as an email “we need to build a CMS system that will support all our portal needs”.
Now there was an end goal defined, someone just needed to sit and figure out what “all our portal needs” were. Someone needed to define what this CMS was going to be used for. When would it be considered complete.
I guess being a physicist I tend to always take the abstract, break it down to well defined pieces and solve it. But I need that problem statement: what are we trying to solve to be very well defined.
So much for today …..
Reply
Begin the journey
On the other hand, sometimes we must be explorers – not always knowing the precise destination.
I’m in agreement that we can’t be wandering about throughout a project. Yet, when we encounter unfamiliar territory (and isn’t that a pretty common place these days?), we may want to send out scouts – trying a few paths. We may be able to eliminate unpromising approaches and perhaps “triangulate” onto the right path.
Reply