The Secret Sauce, Ep. 28: Project Stewardship and Understanding KPIs

KPIs are the driving factors for any web project, and Project Stewards make sure these goals are reached.

On this week’s episode of The Secret Sauce, Joe Allen-Black and Luke Wertz explain how Project Stewards use a collaborative process to help our team fully understand and meet our clients’ business objectives and goals.

iTunes | RSS Feed | Download| Transcript

Subscribe to all of our episodes over on iTunes.

Stay connected with the latest news on web strategy, design, and development.

Sign up for our newsletter.

Transcript

Allison Manley [AM]: Hi everyone, and welcome to The Secret Sauce, a short podcast by Palantir.net, that offers a quick bit of advice to help your business run a little better. 

I’m Allison Manley, an Account Manager, and today we’re talking about Project Stewardship with Joe Allen-Black and Luke Wertz.

Luke Wertz [LW]: Hello, I am Luke Wertz. I am a senior engineer and a team lead here at Palantir.

Joe Allen-Black [JAB]: Hi, I’m Joe Allen-Black. I’m a project manager and a strategist here at Palantir.

LW: So today we wanted to take a few minutes to talk about this concept of project stewards that we have here at Palantir. When we’re planning out a project and planning for a project’s success, one of the first things that we do is try to identify individuals within our project team who will be responsible for ensuring a project’s long-term success, from the very beginning all the way through completion of the project.

JAB: What we want to make sure is that the success is defined not only by the fact that the website does everything that they hope and want it to do, and we’re able to feel great about the work that we can do, but we also want to be sure that we’re doing it within the budget constraints, within the time constraints, within whatever kinds of issues happen to be coming in — we want to make sure that we’re making the best site for all the different situations that we have.

LW: Yeah, exactly. We have come to this point of trying to identify two people to do this, from a long history of only having one person that tried to embody this from the beginning of a project to the end. And that person ended up going through some unusual changes during the course of a project, needing to wear many different hats: the business analyst hat, sometimes just having to refer to that person as an analyst, sometimes as an architect, sometimes as a technical lead, sometimes as a team lead — it got to be a bit much. And it was oftentimes difficult to transition well from the strategic planning parts of a project, that typically happen quickly very early on, and then into architecture and technical implementation. So we identified that this need arose to have two people playing this part on a project, and to work as a balance and counterbalance for each other.

JAB: What we’re ultimately trying to do is make sure that throughout the process our clients understand why we’re coming up with solutions, why we’re coming up with suggestions, as to how we can best work with them. And during the types of projects that Luke and I are on, part of my role would be to go through and determine some of the different features, some of the different ideas that we want to have the site include. And then, working with Luke, I’ll try to help facilitate the best way we can implement those in maybe the best order for those. The technical side is left to smarter folks like Luke to figure out, obviously. And then we try to make sure that together that the options are the highest-quality technical answer that fits within the constraints we have on the project.

LW: That’s exactly right. We spend a lot of time talking about what our client’s business objectives are, and their goals. And where I really rely on somebody like JAB, or somebody in JAB’s position, is to really have a deep understanding of the client’s KPIs and what those might look like in practice. And having somebody who is a co-worker and colleague who does that, and not being reliant on a client stakeholder to do that for me — it allows me to workshop ideas and to architect these incredibly huge, sometimes overly complex — some might be so bold to say, over-engineered solutions, and have a friendly face telling me, nope, go try again.

JAB: It’s friendly sometimes, you know, depending on the type of project [laughs].

LW: It’s always done in love [laughs].

JAB: We want to make sure that, when we come back to our clients and make a recommendation, we’ve been able to talk and that we understand the vantage points of both of us, and that we’re able to go, considering what we want to do. We know that we should spend a bit more time on making sure your workflow is the best, because that’s a pain point to you, and we might do that rather than spend a lot of time on some other part of the project. Or depending on the project it might need to be made sure that speed is in there, or that there’s something else that needs to be enhanced, and that might have to come at the expense of spending time on something else. What Luke and I are able to do is to make sure that we’re really keeping each other in check, and then we bring back the best possible options to our clients, to make the ultimate decisions on how they want to spend their budget and want to spend their time, but knowing that they’ve got great feedback from two folks looking at it from different vantage points.

LW: So what this looks like in practice for us is, starting from the first inkling of a project, when we’re still just in the very early stages of talking with a client about the potential of what they want to build, we will assign two people as a strategist and as a technical lead. And it is their job to be involved from the very first conversations we have about the actual production of a site to sit in together and to hear the same things from their own unique expertise, and to be able to hear from the clients and the many stakeholders that are often involved in those early conversations, so that we can fully encompass both the business needs and the technical needs that may be constraints or desires on the project. So we start this process early on, and build a very collaborative process where we’re checking in very frequently, we’re documenting separately the things that we hear, and then bringing our notes together and making sure that we’re hearing the same thing and are able to capture the same vision for what the final product is going to be.

JAB: Then throughout the beginning of the process I might be introducing different concepts for how we want to organize our data, how we want to have different pieces of the site speak to different audiences, while Luke is giving ideas on how we would structure that data, how we would be able to put that in a way that, at the end of the day, somebody’s going to be able to see that on the Internet or whatever type of tool that we’re building. And as that continues going on, we work with our client to get to the best ideas. As his team keeps working through the development, my goal will be make sure that I’m able to follow up, can take a kind of different view of it, gut-checking, to make sure it’s working the way we were expecting and for the right goals.

LW: So we’re both definitely involved from the beginning and throughout. But the place where our two separate disciplines and our mutual responsibilities as stewards on a project intersect is at the data model layer, which is a very developer-y buzzword. That’s my word, not JAB’s. But the output of our data model is typically a complete definition of all of the pieces of information that are going to be on the project, and what those pieces of information encompass. And so Joe has worked very hard up to that point to get a full understanding of the individual pieces of information that are necessary to meet the goals and KPIs of the project, and I’m working alongside him to define reasonable ways of storing those pieces of information in a well-defined database and data structures. And so the output of that process is a data model that the development team can then use to begin layering interactions and relationships, and begin to see the vision of the full thing come to fruition.

JAB: It’s definitely measure twice and cut once. So we’ll spend a lot of time talking about, what are the types of pages that we need, what are the types of elements, and then how do we break that into fields and how do those relate. So I will be talking with the client or with the people that we’re working with, and saying, hey, we really need a categorization that helps us bucket these items together. Or Luke will take that, and using a term like ‘data modeling’, turn that into what that’s going to look like on the back end, and how can we be sure that we don’t blow up the internet by putting a bunch of code out there. So we’re able to have that approach in two different ways that ultimately hits that goal.

LW: At the end of the day, what we want to make sure is that any client we’re talking to, any client that we’re working with and trying to build a project for — we want to make sure that we have the right people around the table or the Google Hangout, as the case may be to make sure that we’re hearing correctly and exactly what the client needs. Because it’s not until we can fully understand what the client needs that we can build for them exactly what they want. So that’s really the role of the project stewards: it’s to be there at every moment of the project to ensure that we’re hearing and we’re listening and we’re responding appropriately. Thank you very much.

JAB: Thank you.
 
AM: Thanks Joe and Luke. That’s the end of this week’s Secret Sauce. For more great tips, check out our website at palantir.net, and check us out on Twitter. Our handle is @palantir. 

Have a great day!

Project Management