Bas de Baar is a Dutch visual facilitator, creating visual tools for dialogue. He is dedicated to improve the dialogue we use to make sense of change.
As The Project Shrink, this is the riddle he tries to solve:
“If you are a Project Manager that operates for a short period of time in a foreign organization, with a global team you don’t know, in a domain you would not know, using virtual communication, high uncertainty, limited authority and part of what you do out in the open on the Internet, how do you make it all work?”
In the early 1980s I received a postcard from my friend Bob. He promised I would get hundreds of postcards from all over the world send to me. By people I'd never heard of. It was a chain letter. It worked like this: on the card is a list of 5 names and addresses. You are supposed to send a postcard with your name and greetings to the first address. Than you invite five of your friends to participate , in the same way Bob did to me. And here comes the twist: on the invitation you'll write a list of 5 addresses: the first four are the last ones on your invitation to participate (in my case Bobs card) and you put your own name and address at the bottom.
If each of your five friends sends invites to five of their friends your name will be on spot number four on 5x5=25 invites. When you reach the number one position on the list, that specific list will be on 5x5x5x5x5=3125 invites. And each will send a postcard to the top of the list: you. That's the promise of a full mailbox.
I knew Bob. I wasn't supposed to take him too seriously as he was mostly fun and games. The promise of 3125 postcards was too good to be true, so I wasn't going to take his word literally. But with all those numbers, you should be able to get some exotic postcards, right? I decided I was going to participate. It would only cost me six stamps, so even if I wouldn't receive anything, the cost wasn't going to kill me. For a short moment I hesitated to send something to the first person on my list, I could con the system easily. But for some reason I participated exactly as instructed. Sent six postcards and waited.
In the course of three months I received four postcards. Three from The Netherlands, and one from exotic Germany.
Two years later I received an important looking document sent to me by a professor with an unpronounceable name. He promised me I would become rich. People I didn't know, from all over the world would sent me money. It was another chain letter, also sent by my friend Bob, who had copied a letter from a professor, or at least someone with a lot of acronyms before and after his, unpronounceable, name. This time I wasn't suppose to sent a postcard, but 10 US Dollars to the first name on the list, and there were 10 names on the list, instead of five, and should invite 10 friends. 10.000.000.000 ten dollar bills was the promise. That is serious money.
For a fifteen your old child at that point of time, around 1985, that Xeroxed document looked very impressive. It had stamps and names of important sounding people. I decided to go for it. Sent 10 bucks to the first name on the list. Not only because I wanted to get rich, but also because all the cool kids in my school had entered, and they got together every day to talk about what they were going to do when the money-train would roll in. I wanted to participate in that chat. Because it was the cool thing to do.
We talked for almost a year. No one got any money what so ever.
Of course in the face of today's digital world, with scam artist filling your mailbox every hour, this might sound pretty naive. Well, it is. But in my defense, some of these chain letters actually worked to some degree. And that is fascinating. You have to give something to someone you don't know, based upon a piece of paper. Your reward is depending on the individual decisions of members in the chain: "Am I going to give something to an unknown individual based upon a piece of paper?"
The chain letter might be dead, this dilemma isn't. Actually, the Internet has turned almost the majority of social interactions into a Chain Letter Dilemma. Digital media allows you easy and fast access to people you don't know. It also allows them access to you.
"Are the expectations of stakeholders important to a project managers? And how do you get to know what they are?"
From the question I guess you already know the answer. So here you go: yes, expectations are VERY important.
What people (and therefore your project stakeholders) really, really, really want is what can be termed their interests or, as I sometimes call them, their stakes (hence the name“stakeholder”). With fears there is a stake to lose, and with wishes there is something to gain.
In this context, I consider interests as the aspects that drive people. Before you start drawing your “interest evaluation diagram” or some other tool or technique, be aware that in general these interests are hardly ever communicated. It’s pure mind stuff, all inside the head of the owner. A four-year-old boy may share his true interests with you, but the
fiftyyear-old graying accountant will tell you nothing.
If no one will tell you anything, what is the point? People will tell you something if you ask them. They will tell you they want an ice cream cone, a new hyperspeed Internet uplink, or a new financial software package. In essence, they tell you what they expect. It is a statement created by themselves about a desired situation: their expectations.
So the expectations are indicators about what they think they need.
We can ask them flat out what these are and throw in some other questions to provide us with some useful extra information. You can send these inquiries by e-mail and ask that the responses be returned by e-mail. Especially when the number of stakeholders is large, it’s a very nice, convenient method.
You can include the following questions:
1. What are your expectations of the project?
Just phrase the question as boldly as you can.
2. What is the purpose or mission of the project team?
This Indicates what the stakeholder thinks is the goal of the project.
3. What benefits do you need from the project?
What does the stakeholder have to gain from the project?
4. What are your highest priorities?
Are there any conflicts with other issues? How important is the project for this stakeholder?
5. What resources are you willing to provide to the project?
This indicates the level of commitment and participation.
6. Do you expect some negative consequences from the project?
Has the stakeholder something to lose in the project?
7. What outcome is needed and/or expected from the project?
This gives you explicit expectations about the project results.
8. When should the team’s work be completed? What milestones do you expect?
This gives you explicit expectations about project process.
9. What is the business case for the project?
This indicates the expectations for the business.
10. What organizational policies influence the project?
Policies can be regarded as expectations of the organization.
11. What are your experiences with similar projects (personally and/or departmentally)?
History determines one’s current expectations.
"Dear Project Shrink: The people from our technical support department always seek unreasonable arguments not to take the system into production. Now they need tons of documents, later they need to see more test results. What should I do?"
Transition from project to production is always an exciting time. If the project was a long and painful ride, it is the time for relieve for the project team members. The end of their misery. Slam dunk over the wall with the system, and their problems. In this case, it's no surprise the support department doesn't want your misery. So, they just keep piling up the arguments not having it as their responsibility.
Or, you actually agreed to deliver documentation and test results, and you didn't. When time is scarce the person in a business suit with the wallet has priority, not the maintenance guy in greasy jeans. So, it might be that the requirements from the support department got lower on the priority list. Too low.
I would recommend doing two things to avoid this situation: get a support guy on the project team. Make sure that some one that will be maintaining the system during production is part of the project from start to finish. This will ensure that you have no surprises at the end. You possibly still have to deliver those items, but you get your signals earlier.
Second, from project start, formulate all the requirements from the technical support department into "business requirements", like availability; arguments all stakeholders can relate to. This makes discussions about priorities during the project a lot easier.
For example a requirement like: "Every database should be Oracle." (or just pick a vendor you like). When buying a system, it can be simple. "Does it run Oracle? No? Sorry, we don't want it." But, normally you buy functionality and not technology. Especially a business person doesn't care. You buy a system for what it can do, and not because the bits and bytes are flipped in a certain way.
The stake here has to do with sharing database administrators among several systems. The company benefits from efficient use of employees. Especially concerning specialized people. Database administrators (DBAs) are a good example. Having more similar systems that these people can maintain, will make the costs of maintenance drop. Using a more mainstream database like Oracle, makes it also easier to get some outside people from the market to do the tasks when your own employees are overloaded or not available.
Now every person understands this.
So, one person on the team, and sharing the rationale and importance behind technical requirements with all stakeholders should help you out.
In the final part of my talk with Peter Taylor, The Lazy Project Manager, I ask him how he explains what he does to his children. This was right after a talk he did at the PMI EMEA Congress. In it he made a case for Project Managers to get "out of our box". He said that we are unknown outside our profession. How do you explain to your kids what you do? So, I asked him.
