Friday, March 27, 2015

How much concrete do you need to build a happy home?

Imagine you're building your house. You will probably try to translate the options you are faced with into the benefits you and your family can get, that is, you may decide to build a back porch if you want a place to get all the family together (in this example, the option is to build or not to build a back porch, the benefit is to have a place big enough for the entire family). On and on, your aim is to build a happy home. Right? On the other side, the constructor has to put a dollar figure on it, right? He has to figure out how much of each material is needed, how long will it take to place it and how many people will he need for each necessary skill. In short, your constructor will have to answer questions such as this:
How much concrete do you need to build a happy home?
Easy, isn't it?


Context

This article is in fact about projects and programs. You might think that you know the difference but the truth is there are some misconceptions about these simple concepts. Probably you have the notion that a program is just a set of at least 2 related projects, right? Well, that is not exactly true, although it is what is more commonly meant by program. For starters, let's take a look at what the PMBoK (Project Management Book of Knowledge) says about it, OK?

What is a Project?

A project is a temporary endeavor undertaken to create a unique product, service, or result.
in PMBoK 5th Ed., page 3
So a project is about getting a unique product, service, or result - which looks a lot like the constructor perspective from the start of this article. In fact, all the constructor needs to move to his the next project is to deliver you your new home. But for you, it doesn't end there, does it? In a sense, that is truly the start of something new: next you have to move your family and all your stuff to the new house, you probably have to discuss and adjust routines such as who uses which bathroom in the morning, re-adjust the cleaning schedules and so on. Right? So your project is longer than your constructor's - which is really odd since it is the same project they both should end at the same time!
Now is the time to take a look at what a program is and we'll take a look at the same book where you can find a program defined as:

What is a program?

A program is defined as a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program.
in PMBoK 5th Ed., page 9
This looks like a better match to your concerns on building your home than the project definition, doesn't it? Mainly because of these 2 bits:

1. To obtain benefits not available from managing them individually

In fact, you're looking to obtain more benefits than a place to sleep in, right? Just like a house benefits you more than the sum of the benefits of the walls and all the other components of your house, your new home will benefit you more than just any home because this one has all the things you need for your family to be happy in - it can be a barbecue grill on the back, a really large table, a small garden, a swimming pool, a back porch or even to locate the bedrooms upstairs. For some other person, the requirements for their family to be happy in their new home could be quite the opposite - for instance, it could be they find it necessary to have just the ground floor so there is no unnecessary obstacles for the older people or people with some handicap.

2. Programs may include elements of related work outside the scope of the discrete projects in the program

While the constructor's work ends the minute he delivers you your new home, some more work starts on your end at that time: you'll need to move everything from the old house to the new one, you'll need to change the contracts for water supply, electricity, television, telephone and internet, buy some more furniture and some curtains that you also need to have installed. And you may also need to find a new school for the kids, plan a series of weekend lunches to have family and friends in your new house and so on.
And so the work continues after the project is delivered. It's just like any other project where something is delivered that is intended to bring a specific business benefit that goes way beyond the delivery itself. For instance, you can be upgrading some system in the organization in order

Is it a project? Or is it a program?

That doesn't depend on what you're managing - it depends on how you want it managed. So the same thing, for instance your new home, can be both a project to the constructor and at the same time it can also be a program to you. Right? It isn't an intrinsic quality, it's an extrinsic quality, so it can actually be both at the same time. This is a bit counter-intuitive, I think. I couldn't find a place where this notion was explicit, that is, that something is a project accordingly to the way you manage it. But I couldn't find any reference where it said otherwise. So please give me some slack and get back to me if you can help get this straight.
But for me, the main difference between a project with a few sub-projects and a program with a few projects is just this:
A program is focused on the business benefits (the outcome) while a project is focused on project results (the outputs).
Note: to go a bit deeper into this output/outcome discussion please check "The Art of Funding and Implementing Ideas" published in 2011 and "Projects and Programs Objectives" published just over in 2014 which were really in the origin of this perspective.

Is this why it's so difficult to communicate requirements?

Right on, it's just because of the different perspective. On one side you have the perspective of the benefit: you want the best possible house for you and your family, the one that will allow you to have the entire family together in the weekends or a swimming pool for Summer pool parties. On the other side your constructor has to find a way to hand you a budget and say: it will cost you this much and it will take this long to build.
The exact same thing is valid to any other project: no one is looking for software with this and that feature. what you really want is to address some business problem with that piece of software. But to do that, you have to somehow translate

  1. what you imagine is the software that will solve your business problem
  2. into software features and even software requirements.

And if you hire someone to build that particular piece of software, it's the same question you're asking that team to answer, and that is:
How much concrete do you need to build a happy home?

Conclusion

Lat November I participated in Michael Smith's Conscious Software Development Telesummit where I talked about Projects and Programs in a 30 minute interview. Actually, this interview was based on the paper "Projects and Programs". Is was then, when I was preparing the interview, that this idea was born. It started taking form from as far back as 2011 with the article "The Art of Funding and Implementing Ideas", but it was only then that it took a definitive shape.
And so I ask you to contribute to this discussion: Are projects and programs a property of the things being managed, ie, are they intrinsic properties? Or are they properties transmitted by the way you're managing them and they are truly extrinsic properties that can be both projects and programs at the same time depending on the perspective you take?



Image from http://momsopinions.wordpress.com/

No comments: