Today I listened to the recorded PMI IS CoP webinar called Tearing Down Project Barriers Between the Business and IT.
The webinar speaks to IT as a tool to achieve business goals of an organization as opposed as IT as its own beast with it own goals. I believe the same focus, on business goals, should be applied to other business entities like marketing, accounting, and production (includes engineering, construction, software development, etc.). Business entities serve the business, not the other way around. Just look up business score card approaches for more on the subject.
The webinar identifies problems with project inception or concept as a major culprit. Imprecise scope, inflated expectations, immature technologies, and hype. Business user many not speak the language of your domain; you have to align and adapt. Business users may want something that is hard to do but you have to help them understand that and that difficulties may have to be surmounted for them to get what they need. Hype usually “forgets” that there are implementation difficulties.
Alignment between stakeholders or business entities is essential but very tough to reach. By the time the project is recognized as such, expectations (realistic or not) have already been brewing for a while. Often time the inception process has been going on in a vacuum. Various stakeholders may add requirements that satisfy their business entity but take the “project” away from actual business goals. Think of a product designed to sell at a given price point; it may not be enticing to the consumer because it lacks certain features. Think of a product designed to yield a given profit margin, it may be very inexpensive to produce but no one wants it because it is perceived as cheap. Think of a product that I seen as easy to bring to production; maybe it is already obsolete compared to what the competition has. Also, if the expectations are not aligned with the capabilities of the organization, there will be pushback from the project team.
Gaining alignment requires active guidance. This process documents requirements, assumptions, risks, organization capacities, etc. At this point you have a project manager, maybe a system architect, maybe a business analyst, maybe a quality assurance person, but no project team. At this point you are just not ready to roll. If you did you may run into one or many walls around technology, schedule, or economics.
Maintaining alignment also requires guidance. The same team of people guides the project team in staying the course, preventing scope creep and likely unmet expectations on features, schedule, or cost.
What do you think? As always questions and comments are welcome.
Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.
Comments