PROJECT PARENTHOOD

Ownership of Outcomes

by Geof Lory


Recently I have been working with a group of project managers and software developers trying to settle on a lean yet effective team and process model. They want a framework that guides the activities of the different roles on the team throughout the project without becoming too prescriptive. The danger in prescription is that it is both difficult to account for every situation, and any attempt will almost certainly create job silos that work against the necessary communication inherent to great teams.

One of the ways to capture this at a high level is to create a roles and responsibilities matrix. It helps answer the question, "who is doing what when to deliver what?" I wrote about this in a previous article, so I won't go into it in any more detail here.

When creating these roles and responsibility matrixes, it is common and helpful to start the activities being performed by each role with verbs that are indicative of the level of involvement of that role. Words like design, develop, test and facilitate are well understood by those performing the activities and require little definition. However, as we were reviewing a draft of the matrix, one of the team members saw that their activity was to "own the _____." (You can fill in the blank with several different project deliverables, depending on your role and the phase of the project.) He looked at me and asked, "What does that mean, own?" I couldn't help myself; I immediately slipped into a story about my experience as a parent.

A few months ago my oldest daughter was going to a dinner banquet for the high school play she was in. It was a big event held at the local country club, and she wanted to look her best. She told me a week or so before the event that she wanted to go out shopping for a dress for this event. I told her that was fine, and to just let me know when she wanted to go and I would take her. Like any busy parent, it quickly fell off my radar screen until 9:00 pm the night before the banquet. Jenna came up from doing her homework and informed me we needed to go to the mall to get her a dress. Obviously, we were not going to go at 9:00 pm, so I asked her when she was planning to go shopping. She suggested we go the next day, right after school, and during my work day.

Now, the girls have access to my electronic calendar, (the same as most people do in a corporate environment), and had she checked she could have seen that I was delivering a seminar for a client until 5:00 pm that following day. With the commute home, that would leave me 30 minutes to get ready to take her to the banquet. After the obligatory ranting over being seen in the same dress as some previous event, she attempted to lay the guilt on me for not remembering to take her to the mall earlier. She even reminded me that she had told me we needed to do this almost a week ago. "Why didn't you take me shopping earlier?" she whined. I looked at her, conjuring up my most sympathetic paternal voice and said, "Jenna, I don't own this problem. You want the dress, getting it serves your interests not mine, you know what you want, I don't. I'm merely the vehicle to make it happen. If you wanted that outcome, you needed to drive it, not me."

That's my explanation of owning an outcome. If it serves your interests to achieve an outcome you are responsible for or want, you own it. It now becomes your responsibility to drive to that outcome. This is not the same as having a personal agenda and working toward your self-serving interests though. On projects, we all have our individual talents that we bring to the team, and we all have our individual perspectives and focus. We each represent some stakeholder to whom we are accountable, and it is our responsibility to adequately represent their needs. That is the value of diverse teams.

In cross-functional teams, like most software development teams, the management of these diverse talents and perspectives is a unique challenge for the project manager. I read a statistic that in 1970 the average worker had 80% of the skills and knowledge necessary to perform their job. In 2000, that number is less than 20%. A definite cry for collaboration if there ever was one, but also a recipe for the fabled Tower of Babel. Having a common understanding of who is driving what outcome, or who owns what deliverable, even though they may not be capable of doing all the work themselves to create the outcome, is key to success in today's teams.

As a project manager, schedules are important to me. I own them. So are budgets; I own them, too. I don't usually create either of them on my own, but the organization holds me accountable to them. Keeping them updated is often a challenge; when providing status reports, task progress or hours are not necessarily on the top of everyone else's to-do list. Nonetheless, I nag and cajole to get what I need—I own the schedule, and the schedule is a key instrument to the whole team achieving success.

Another way of phrasing this is to think of it in terms of what I deliver, not in terms of what I do. Designing, developing, testing and facilitating are things you do—essential and important, but not as important as the outcome of that doing. The owner of the outcome is the one who makes sure the doing gets done or they incur the consequences. Ownership creates drive and drive creates results. I like knowing who owns outcomes.

So, what did Jenna wear to the banquet? Trust me, she is a 16-year-old with more clothes than she has closet space for. She didn't suffer any social humiliation. Even though we didn't go out and get her a new dress, she still owned figuring out what she would wear. That is the great thing about ownership, no one else cares about what you own as much as you do, so trying to give it away is useless, at least to this Dad.







©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy