Encapsulation in Project Management

About
April 11, 2009 @ 2:25 pm

Encapsulation is a concept used in object-oriented programming that allows code to scale and be refactored without taking down the entire system. In coding, encapsulation states that my code can call a function (giving it the required parameters) and it will get the same result back every time exactly as expected without needing to know what went on inside the function itself.

When translated to project management, encapsulation can increase productivity, ingenuity, quality, trust and morale. It establishes a connection between responsibility and authority — a key component of project management.

First Things First, Defining Encapsulation

Simply put, encapsulation is abstracting the completion of a task from how that task gets completed. These two aspects are connected by something called an “interface.

Interfaces

When most people in our industry hear the word “interface,” they think of a “user-interface.” Obviously, a user-interface is an interface, but it’s just one kind. Since it is the most common, let’s roll with it. When users are using functionality that you’ve created — a contact form, for example — they are looking to accomplish a task: they want to ask a question to which you’ll answer.

The instructions that you provide, as well as the text-fields and buttons you give them are the interface by which the task is started. By validating the form, you are ensuring that the user has provided all of the required information needed to accomplish the task. After form submission, the user is alerted that someone will be in touch within two business days.

And a day later, the question is answered.

The Glory of Encapsulation

Notice that before that last sentence I left out a lot of stuff? How did the message get delivered? Via email or text message? What research or resources went into finding out the answer?

The glory of encapsulation is that to the user, these things doesn’t matter.

interfaceHere is a less technical example of encapsulation at work. A kid wants a green ball, so he asks the interface for one. In a couple of minutes, he is provided with the ball, exactly like he asked for.

(Look at how happy he is!)

Where did the ball come from? What’s on the other side of this wall that create these balls? How many people are over there studying and researching to create better and more cost-effective balls? As long as what came out was exactly what was expected by the kid, none of these questions matter to him. He fulfilled the interface requirements (providing the shape and color), and got what he wanted. If he asked the interface for the same shape and color again, an identical result would come out.

How This Applies to Project Management

Encapsulation should be used in day-to-day project management to solve three common management dilemmas:

  1. Micromanagement
  2. “Too many cooks in the kitchen”
  3. Responsibility without authority

Step back for a moment and consider the bigger picture: the contract with your client is nothing but a large interface.

Your client brought you a project request, an amount of money they will pay for it and the time by which it must be completed. You’ve agreed to get it done. You shake hands to signify that the interface’s parameters were fulfilled successfully.

From here, most of the particulars of how the project gets done isn’t important to clients, as long as you deliver exactly what is expected on-time and on-budget.

In turn, you can think of that project as being a collection of smaller “sub-projects.” Assign one of your team members to be a “sub-project manager” for each of those sub-projects, making that person solely responsible for seeing it through. (Or, to continue the green ball metaphor, you be the kid and they’re the guy behind the wall.)

Create an interface with them:

  • Describe in detail what must be accomplished to complete the sub-project
  • Set the time and date by which must be completed
  • Set any limits on a budget for them to work with
  • Confirm that they understand the task that they are responsible for
  • Inform them that they have the authority to use any means available to them

And Then What?

And then you turn them loose and trust them to make you proud.

Show up at the agreed-upon time, collect your agreed-upon deliverables as was defined in the interface and move onto the next sub-project. Just like the kid in the example: who knows what went on behind those bricks — your sub-project manager may have recruited other team members, may have made deals with other teams around the office creating interfaces of their own, or may have even ask their NASA-engineer brother for help on the weekends.

Most importantly: who cares?

Part of your sub-project manager’s responsibility is ensuring that any new interfaces that they’ve chosen to execute fits inside the interfaces they’ve already been bound to fulfill. Giving this responsibility-with-authority empowers your team members to be more than just “the people that do the work.” They become “people that get the work done.” Your trust and confidence in their ability to make things happen boosts team moral and relieves you of the stress of juggling too many items at once.

As a project manager you can’t be expected to be a master of every skill required to complete your project, you just need to know what isn’t possible. With that in mind, let the people on your team do what they were hired for: creating the most appropriate solution for the task they’ve been given. This leads to higher efficiency and, typically, better results.

And That’s It?

Well, rinse and repeat.

Encapsulate each of your sub-projects until all of them are complete. Of course, it’s impossible to fully stay away as a project manager. After all, while internally your team fully trusts encapsulation, the client paying for all of this is going to want updates.

It may be worth setting up milestones as part of your interfacing with your sub-project managers. Let them know that you’ll need updates to coincide with your schedule. Try not to spring these updates on them as they, like you, have a schedule of how things are getting done.

Finally, once your project launches, step back and ask the magic question: how did that go?

Review for Efficiency

It will take some tweaking to adjust the size of the sub-projects so that your team members (sub-project managers) don’t become either bored or overwhelmed. Have a small internal review after each sub-project completes to make sure your project is still on track and your team’s spirits are high.

Through encapsulation, everyone in the team gets empowered to make decisions. Having the control to get things done the way each person individually works best lowers the overall project stress and improves the results. So give encapsulation a try; start small and work your way up. You’ll be amazed at the results that you start seeing right away.

Comment Feed · 3 Comments

  • Fred, great article - as a project manager myself, I deal with some of these same challenges, and while I’ve never thought about it in these terms, I think this is a good paradigm to view management in.

    One area of this article that I was hoping you might get more into as I made my way through it was the notion of “what happens when your people don’t make you proud?”. I’m not trying to be the “skunk in the room” (what a funny phrase that I heard recently) - but I think that’s the biggest challenge that I run into on a daily basis - that being, this idea that things just don’t always work that smoothly - and in the end - as good project managers, we ensure that the ball does come out on time, the right color, and in the right shape - and the smile persists on our our client’s face - BUT - the details…the behind the scenes stuff - the personal interfacing - the personalities - the challenges to our authority, the egos - all the things that go on behind that wall - I think that’s the biggest challenge of all and requires the greatest effort and strategy - don’t you agree?

    I love these types of articles - I hope you write more - and if you are the illustrator - you could seriously write a great management book some day and do all your own stick-figure illustration - GENIUS… Okay I’m done.

    Comment by Ryan — April 13, 2009 @ 10:08 am

  • Ryan: You’re right, but that topic is a whole other (set of) article(s). AS such, I plan to write out a whole series of these articles as I’ve learned a ton and I think it’s worthwhile information to share.

    And yes, that illustration is my handy work with a tablet and about an hour of Photoshop. I need to get more efficient.

    Comment by Fred LeBlanc — April 13, 2009 @ 10:14 am

  • @Ryan : fair enough
    @Fred : waiting your set of articles

    Comment by Web Shop — April 21, 2009 @ 3:27 pm

Sorry, the comment form is closed at this time.