Skip to main content

Author: Hans Jonasson

Creative Expansion – Scope Creep Upfront Instead of at the End

Written by Hans Jonasson on . Posted in Articles. 4 Comments on Creative Expansion – Scope Creep Upfront Instead of at the End

Scope creep tends to be one of the most common problems in projects. We are very focused on minimizing scope and then trying to stick to it. Well, one alternative can be to try to do scope creep upfront, before we sign the contract with the customer. A few years ago I began a long overdue kitchen remodeling project. It is one of those projects that lends itself very well to scope creep (or in our case, scope leap).

When I do projects, I normally go into them with the mindset of defining and locking down scope as much as possible, as early as possible. I want the customer to be focused on their needs and not stray into too many other areas. Well, Donna (our kitchen designer/project manager) had a different approach. She encouraged us to look at as many ideas as possible, go to different manufacturers, look at pictures, come up with as many ideas as possible.  

At first I thought this was a frustrating approach. I want action and don’t have much patience. My approach would be to show me three kitchens and I’ll pick one. That is, until I heard Donna’s reasoning. She said, “I don’t want you to come to me at the end of the installation and tell me that you’ve seen something else that you really love and that you wished you had picked. I want to make sure that you’ve seen everything out there and have made an informed decision.” 

One of the phrases I’ve heard in project management describing this approach is “Creative Expansion”. What this means is that before you start an actual project or solve a problem or need, make sure that you have explored multiple options with the customer. If the customer is looking for a sales tracking system, bring in packages and prototypes, go to trade shows, organize brain storming sessions. Don’t be afraid of exploring options that may not be realistic. What this will do for you is that when the customer comes to you the day before implementation and says, “I just saw this great solution to our problem on the internet last night”, you can say, “Good idea, we actually explored that early on, but found that it didn’t really meet our need, and here’s why…”.  

I am not a believer in that one size fits all. Often, just going for the obvious solution is right. But I do believe that very often when we, as project managers, push for a quick, firm scope definition, we are just setting ourselves up for customer dissatisfaction, change requests and rework. Take a look at your next project and ask yourself, “Is this a project where we want to do some creative expansion with the customer before we select our approach?” It may do wonders for your long term customer satisfaction.

PMI is Taking Over the World…!

Written by Hans Jonasson on . Posted in Articles. 2 Comments on PMI is Taking Over the World…!

How’s that for a heading? Exaggerated? Cheap shot? Maybe, but probably also with a bit of truth. Opening the PMBOK 4th edition I saw that PMI has added “Collecting Requirements” to the core processes and this immediately made me very uncomfortable. I have been in the PM business for 20 plus years and in the requirements business even longer, and I have always talked about the importance of separating the ownership of the product definition from the ownership of the project execution. The ownership of the product definition lies with the customer, or the buyer. They are the ones that must define what they want, the capabilities and functions that they are looking for in a product. The project manager represents the seller, or the developer, and as such their interest is often in direct conflict with the buyer.

Now, this does not mean that the project manager does not need to be involved with driving the project and the requirements gathering and even, in many cases when you are working on internal projects, be the person actually documenting requirements. But it is noteworthy that when the project manager acts in this capacity, they do it representing the customer organization They should be aware that they are wearing two hats and may have to develop a split personality. So while in real life this often happens, it is preferable to split the job of requirements gathering between the business analyst (or whatever you call that function in your business) for all product related requirements, and the project manager for all project related requirements. These requirements should be documented in two different documents with different ownership. The product requirements goes into the BRD (Business Requirements Document) and the project requirements belongs in the project plan.

It is also clear that the process of collecting requirements in the PMBOK 4th edition could use some enhancements. The inputs are the charter and the stakeholder register. While this may be defendable by making assumptions about what goes into the charter, I think it is noteworthy that, without a solid understanding of the existing business architecture, goals and objectives, strengths and weaknesses and much more, the collection of requirements may focus too much on the project and not enough on the business. And after all, a project that does not help the business achieve its goals is not a very good project.

So… after all the complaining, can say nothing positive? It is clearly good to focus attention on requirements. Many projects fail because of poorly defined, continually changing, and misunderstood requirements. It is great that PMI recognizes and highlights this. And there is no doubt that the project manager must be a major player in this area. Just remember that the project manager is not necessarily the best person to capture and analyze what the customer wants. After all the expertise a good project manager brings to the table is how to implement those requirements.

Good luck and challenge everything!