The Project Shrink

The management of a software project is really an art; it’s a trick that’s difficult to master.  The difficulty lies in the central problem the software manager is faced with, appropriately named “the software project manager’s problem,” as explained by Barry W. Boehm and Rony Ross.  

They believe that everyone affected by the project, directly or indirectly, has something to say, again directly or indirectly, and will do so.  All of them want to get the best from this project for themselves personally or for their (part of the) organization.

It’s the job of the software project manager to see that everyone gets what he or she wants, in one way or another. 

He has to ‘make everyone a winner.'

In this respect, the role of the project manager becomes that of a negotiator. The customer always wants to have it all for free, the user wants to have the greatest functionality, and the programmer doesn’t want to document anything but wants to use the coolest compilers.  The software project manager has to make them all happy.

The entire process of software project management is strongly stakeholder-driven.  It’s their wishes, fears, dreams—their stakes—that determine the course of the project.  

Time schedules, financial projections, and software goals may be abstractions, but it’s the flesh-and-blood people whose work determines your project’s status. It’s the programmer that misses a deadline and holds up everyone else, it’s the financial manager that goes berserk if you can’t produce some good budgetary indications, and it’s the key user that doesn’t give a darn but didn’t tell you about his dismal lack of motivation; these are the folks who can cause serious trouble.  Issuing the best procedures doesn’t mean that people will live by them.  

I know that this socio/psycho stuff is not the favorite cup of tea among technocrats, but being unknown shouldn’t make something scary.  In essence, it’s even easy to understand.  You are part of it.  If you are human, you can practice on yourself and try things out on your spouse  and kids.  Look around your office and try to think about how the situation there is different from the one at home with your
kids.

First of all, your children are more transparent than the people at work.  They  communicate directly what they want, and if they try some power trip on you, you immediately recognize it for what it is.  “I want ice cream right now” is pretty clear.  If they don’t get this very nice cold snack, kids can use crying as a means to get their way. And you may cave in, perhaps just to stop the annoying sound and, of course, the embarrassment of walking through the mall with your yodeling kid.

Let’s start to focus on project management.

Your boss or your employees will not be this explicit and predictable.  They may try some mind games to manipulate you or (let’s avoid being negative) they will have the best intentions, ones you haven’t figured out yet.

But in essence, they have the same mechanisms as you and your children.  People do what they do to realize their dreams or to avoid having their nightmares come true; in other words, to achieve their wishes or to escape their fears.  Within the context of projects, people are the stakeholders.

What people (and stakeholders) really want are what can be termed their interests. With fears there is a stake to lose, and with wishes there is something to gain.

In general these interests are hardly ever communicated.  It’s pure mind stuff, all inside the head of the owner. 

If no one will tell you anything, what is the point?  

People will tell you something if you ask them. Their expectations.

Expectations are a one-sided communication. Requirements on the other hand are a set of statements negotiated among a group of people.  They can be the original expectations, if all agree on the statement itself, but more often than not, requirements consist of some consensus of conflicting expectations.

Requirements are always clearly defined and describe a state that is desired.  This is in contrast to expectations, which are generally vague and abstractly formulated.

Here’s an oversimplified example: an interest of a programmer is “to be involved in way cool new technologies like my brother-in-law is” (let’s say Java).  The corresponding expectation could be, “The system can only be programmed in Java.”  The expectation can be stated along other technical arguments, but it’s only the interest mentioned
that caused it to appear.  If everyone agrees on this “fact,” then “programmed in Java” can become a requirement.

So the project manager has this project, surrounded by requirements that must be met.  But remind yourself: they are
not the stakes, they are not the crown jewels that may not be touched.  So you can mess with the requirements, can’t you?

It sounds simple, but getting the expectations is one thing and discovering their corresponding stakes is another.  

Why bother anyway?   What is it worth?  A lot.  

As mentioned earlier, you can’t effectively change the stakes, but you can alter the set of requirements as long as the new requirements continue to support the stakes.  In this way, there is room to negotiate a set of requirements for the project that poses no conflict, matches the stakes, and thus makes everyone a winner!  Right?

Now let’s take it one step back.  

A stakeholder formulates an expectation for the software project; for example, senior management states, “The project should be finished before the end of August.”  The project manager then has to deal with this time frame. When this deadline is no problem, he can rest assured.  However, it’s a software project, so the deadline will be a problem.  

The way to handle it is to get some information on the stakes that prompted this requirement to be formulated in the first place. Perhaps it’s the old “I don’t want to lose face when my projects get delayed” concern.  That being the case, the project manager can offer alternatives that don’t violate the stake, like keeping the deadline but postponing a subsystem.  Chances are good that alternative requirements that keep supporting the stakes will be accepted—maybe not easily, but project managers should do something to earn their money.

Sometimes part of the project goal is to change a business process. In this video I share with you a great exercise you can do with your (virtual) team to increase their understanding of the change they are going to facilitate.

Previously on Project Shrink ....

“Dear Project Shrink. At the end of the summer I will start a project with a remote team (my first) and we will be using an online project management tool to communicate and collaborate. What should be my number one priority to make a remote team effective?”

If you are starting out in the world of remote team management I would focus on two areas of communication. “What does done look like?” and “How far are we?”

.. part 2 ...  "How far are we?"

When I was a kid my family drove every summer from The Netherlands down to the south of France. I loved those three day road trips. Navigation systems didn't exist back then (yes, I am that old) so my father had written down detailed instructions on how to find our way to the Cote d'Azur.

The drill went like this. He had written down checkpoints we should cross. Like a crossroad, a town, or a specific highway. I would set in the back of the car, leaned forward between the front seats and looking for the next checkpoint. Seeing a checkpoint made me happy. Waiting for one made me anxious. Looking at an expected crossroad provided the confirmation that we were heading in the right direction for our summer holiday.

Time for an awkward switch ... the same goes for projects. Stakeholders and team members need confirmation that you are heading in the right direction towards "done".

This is not just about time and money, but also about the piece of software you are creating. Getting feedback on how far you are enables you provide an informed answer to the question: "How far do we still have to go?" And getting feedback reassures stakeholders that their interests are met. Without some idea of "how far they are", stakeholders get restless.

There are a lot of project management techniques and artifacts available just for the purpose of feedback. Not every time it is clear in these methods that it actually is a feedback mechanism handed to you. E.g. a prototype is feedback to the user how their requirements are translated to a new syste. A schedule: Feedback on constraint “time”. A budget: Feedback on constraint “cost”.

For virtual teams the mechanism of feedback to answer the question "how far are we?" are not really different than with co-located teams. However, because so much feedback is provided unconsciously in a face-to-face setting, it is recommended to discuss with every team member:

• what products are you creating?
• which constraints are you influencing?
• how do we know how far you are on product and process?
• how are you going to show this/record this in our online collaboration environment?

What do you think?
 

In this clip I share with you a simple technique to make your virtual meetings or teleconferences more effective: using a clock as metaphor to create a sense of space.

This week in the Project Shrink question box ([email protected]):

“Dear Project Shrink. At the end of the summer I will start a project with a remote team (my first) and we will be using an online project management tool to communicate and collaborate. What should be my number one priority to make a remote team effective?”

Ah. Your first. I remember...

Your number one priority running virtual teams is the same as running co-located teams: communication. But this time you’ll have to focus your efforts around the online tool you are going to use. In my experience the hardest part will be to make sure everyone on the team is participating in the online conversations. Some people have a natural touch for digital small talk, while others will only drop you a mail to indicate their result is available for download.

If you are starting out in the world of remote team management I would focus on two areas of communication. “What does done look like?” and “How far are we?” This are two essential questions for Project Managers.

What does done look like?

Instead of just assigning your team members their own tasks, you should start your project with explaining what the project is about. What goal are we trying to satisfy? What is the business challenge? What does the result look like? Basically, and that is my favorite way of putting this question, what does done look like?

Your team members will be more effective in their own contributions when they have a sense of the overall goal. They know how their work fits into the whole. When something is unclear, or they need to make a decision or they need have a discussion, they need to know in which direction you should be heading. And there is no way you can answer that question when you are isolated from the rest of the team.

Two simple strategies to let people know what done looks like:

• A description of the goal or business case at a central location. Find an in-your-face-spot at your online collaboration system and put it there for everyone to see.
   
• Create a common understanding, a common view of the goals. One story. Preferably a visual one. Because pictures still say more than something else. Your team can create a multi-media representation of what in their opinion is the project story. They can use their mobile phones to take picture or record short movies, use magazines to create a visual collage or interview their coworkers and write a short story. Discuss the results with the group and create a collective story. It will be fun. And very useful.

Next time I talk about the "How far are we?"-question.