Stakeholder Expectations

Stakeholders expectations are what software development projects must meet if their project managements would have results viewed positively. The path to meeting those expectations appears straight forward on the surface, after all isn't this just a matter of identifying the right stakeholders, gathering their requirements, interpreting those requirements into some form of specification and then developing the software according to the spec? The answer is NO. Not if you want to succeed in meeting those expectations.

Before I get too far into this topic, let me just say that project managers will never be successful in meeting every expectation of every stakeholder. Moreover, if you did succeed in this quest, your success would be fleeting because those expectations tend to change over time. If you want an example of what I mean you need look further than the Manhattan Project. Gen. Groves certainly succeeded in meeting his project objectives but to say that the project did not succeed in meeting all stakeholder objectives would be an understatement. Those expectations changed radically after the first atomic bomb was dropped on Hiroshima; the horrific results of the bomb excited a lot of antipathy towards the project and its product. I think it is safe to say that although none of us can expect to manage a project quite as controversial as the Manhattan Project, the more controversial the project, the more susceptible to negative perceptions we are. So let's focus on meeting the expectations that are within our span of control.

Disregarding controversy for the moment, I think it is safe to say that when we manage projects to deliver cutting edge technology our stakeholders are inclined to give us more latitude in terms of their expectations than when we manage those that deliver products or services that are more common. It's just as well that they do because no matter how careful we are it is humanely impossible to avoid errors and shortcomings in the final product. This doesn't mean that we are forgiven for not delivering on the key project goals and product requirements but we tend to be forgiven for not nailing the requirements 100%.

The progress of artificial intelligence is a perfect example of this tendency. Artificial Intelligence, or AI, is software that is capable of learning. A simple form of AI is the robot that learns how to navigate through a maze by gathering information it learns from bumping into the walls of the maze. Perhaps the best practical example of AI is voice recognition. Voice recognition learns to recognize a speaker's vocabulary from listening to the speaker and verifying interpretations. As each word is verified it is added to the dictionary. Voice recognition is used in the transposing of medical information into documents from doctor's speech, which avoids the tedious business of a clerk taking dictation from the doctor and typing the document.

A story in the Friday, June 25 2010 Toronto Star reports that, although the use of voice recognition software for transcribing medical records is generally viewed as a success, there are still bugs to be worked out. One example of such a bug given in the story was the insistence of the software on interpreting the word "she" as "he". This is no more than a common software bug but the reaction of the doctor reporting the bug was interesting. From his (or her) perspective, the problem was that the software was exhibiting "gender bias" because it persisted in substituting "he" for "she". It is highly unlikely that the programmers responsible for the software intended to make it biased. It is equally unlikely that a bias led to their making the mistake. My point here is that despite this, that doctor's perception is still that the software has a bias. I guess if you're going to hang a label such as "artificial intelligence" on your product you will create an expectation that the product behave intelligently and avoid gender bias.

We should boast about the products and services our projects create. If we don't believe in those products and services then we shouldn't expect the stakeholders to. The downside of this promotion is the expectations we create with our stakeholders. We should take care to moderate our claims for the project so that we can not only meet them in terms of the stated requirements, but in the view of the stakeholders as well. Take advantage of the stakeholders tendencies to cut us slack when we're delivering a product based on a new technology. Set reasonable expectations. The product or service will meet the requirements stated but may not do so thoroughly, in every situation, or elegantly. Present the results as the first step on an evolutionary path. Does the product or service deliver what is needed to solve the problem? Does it perform well given it is the first of its kind? If your stakeholders can answer these questions with a "Yes" you will probably succeed in meeting their expectations. If you create expectations that only a seasoned product could be expected to meet, you will probably fail to meet them.

Those of us managing projects that deliver well established, well known, products and services do not have the luxury of stakeholder slack. There will be no moderation of expectations because of the new technology we use, stakeholders will expect our project to produce a product or service that is better than the previous one. Again we must be careful in setting customer expectations. Make stakeholders aware of the constraints that will limit the feature set and quality level of the product or service we are delivering. We'd like to make an automobile with the quality of a Rolls Royce each time out but when we must build a $15,000 automobile that just isn't possible. The schedule we are given will be another constraint. This is not to say we shouldn't brag about our projects, but rather than say "we're building the best car in the world" perhaps we should be saying "we're building the best $15K car in the world" or "we're building the best $15K car in this market."

We should start by carefully capturing the constraints imposed on our project in the Project Charter and the preliminary Scope Statement where the goals and objectives of the project are captured. They may also be appropriate in the Vision Statement too. If you use a mission statement to market your project to stakeholders it may be appropriate to mention the constraints with the mission statement. However you choose to do it, be sure that you modify your stakeholders expectations for project results with the constraints that will limit those results. The use of new technology or delivering a product or service your organization has no previous experience in are constraints as well so don't forget to include them.

Now that you have set reasonable expectations among the stakeholders plan to meet them. Ensure that your QA test plans are thorough and completely executed. Engaging as many stakeholders, or stakeholder groups, as possible in UAT (User Acceptance Testing) will help to ensure that the project is measured against those expectations. Where there may be some gap between the result and the expectation, such as in the medical record transcription example, inform the stakeholders of the shortcoming. You can do this will a set of product notes that identify the shortcoming and the best work around, or the best way of avoiding the problem. If you put all this advice into practice and still fail to meet your stakeholders' expectations, maybe I've set your expectations for this article unreasonably high!

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP^®courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.