Slik lykkes du med kravspesifikasjon (med Kelly Suter fra BI Worldwide)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: Welcome to the DPM Podcast, where we go beyond theory to give expert PM advice for leading better digital projects. Thanks for tuning in, I’m Ben Aston, founder of the Digital Project Manager. So, be honest, has your client ever turned around at the end of your project and said, “Hey, you absolutely nailed that one, it’s exactly what we wanted, it’s precisely what you said you’d do at the beginning of the project, and it’s just amazing, how you’ve managed to capture everything and not drop things along the way.”

Well, I suspect, it hasn’t happened. And that’s probably because your requirements weren’t nailed down properly. So, how can you manage requirements so you don’t get yourself in a total mess later in the project, but give the client and the developer what they need to know to get the job done. So that’s what today’s podcast is all about, it’s about project requirements.

The way that we define a project, and functionalities for our clients so everyone knows what’s being delivered. Essentially, requirements, I think are a communications tool, but they’re a really hard one to get right, because if we define the requirements too loosely, you give yourselves, well, you know, looser flexibility, but you’re not going to get back exactly, perhaps what you wanted. And if you define them too tightly, you’re going to find, well, there might be loads of things missing. So how do we get this balance right?

So, today, I’m talking to Kelly Suter. Kelly is a technical project manager at BI Worldwide, and one of our resident Deakin experts at the Digital Project Manager, so hi Kelly.

Kelly Suter: Hi there, thanks for having me, Ben.

Ben Aston: No, it’s awesome to have you. I think this is our second podcast, isn’t it?

Kelly Suter: Yes, it is.

Ben Aston: We did a podcast a long time ago. So for those people who have forgotten who you are, do you want to just give us kind of an overview, how did you get into project management, you’ve kind of taken an interesting route, I think, not dissimilarly to most, I think, project managers. We never intended to be a project manager when you grew up, but tell us a bit about your story, how is it that you’re now a digital PM?

Kelly Suter: Yes, so I started my professional career path as a sports reporter, actually, and from there because really I studied Communications with a focus in public relations and media, so when I realized that newspapers were not an up and coming thing anymore, I decided I would look over at the publicity industry, and I was a publicist for about three years, and I did that, it was for one brand, for Sesame Street Live, and so I really nailed down that brand for, like I said, about three years, and I actually had someone who is at a custom eCommerce shop, a digital agency, full service, just focused on eCommerce.

And so, she said, “We don’t have a project management department here, and do you want to be a project manager?” And I said, “What is that?” And my dad actually had a graphic design agency, so all growing up I was familiar with agency process enough to know that it was crazy hectic, always going. But I was like, “Yeah, I’m into it, let’s see what you have over there.” So I went, I went over there, I actually, the first book I ever read, by Meghan McInerny was People, Pixels, and Process. I don’t know if I said that in the right order, but I read that, I applied it-

Ben Aston: I know the one, yeah.

Kelly Suter: Yeah. I-

Ben Aston: People, Pixels … I think it’s People, Pixels, and Process, yeah.

Kelly Suter: There we go. And I applied that best I could to the agency I saw in front of me, at the time it was 12 people. And like I said, it was, we were making custom brochureware in eCommerce sites. And eventually, fast forward about four years, I had grown a team of project managers of seven people and we were able to apply this process that just evolved, it kept evolving, and from there, I thought, okay, I feel really comfortable working with Magento and Drupal and Cantego and you know, WordPress and things like that, and I said, I really want to expand my technical knowledge, so this opportunity of a technical project management position was available at where I am now, BI Worldwide, and so I hopped over here, I really wanted to be back in this PM world, get my hands closer on projects, and sharpen my technical tools. So that’s where I am today, it’s been really exciting, it seems to have gone by in a blink of an eye, but I absolutely love it.

Ben Aston: So I’m always curious, is this kind of now your … Tell me, what is your dream job? It feels like you’ve kind of been on what sounds like, hey, it’s cool, I’m a sports reporter, I work for Sesame Street, now you’re working in tech as a project manager, but what do you want to be when you grow up?

Kelly Suter: That’s a really good question, I think that, oh, I would say that what I like most about what I’ve come into, where I am right now, and where I had been just recently, at Irish Titan, that other development shop, is I love coming into, where it’s very clear that a process isn’t really there or it’s just starting to evolve, not to say that the team isn’t super talented and putting out great stuff already, but I really love taking challenges head-on where there can be process, there isn’t, let’s see what works, and making teams feel that relief of “Oh, we have something to work with, something to lean against,” like putting process in place. So I think my dream job is to be able to be that firefighter, for lack of a better word, for maybe, I don’t know, up and coming businesses, you know, were start-ups just recently, to come in and say “Okay, we know that we’ve implemented this process, let’s see you do it with this one, and this one.” ‘Cause, I do, I love a juicy challenge.

Ben Aston: Nice. That’s good. So, tell me, I mean, what are the challenges that you’re dealing with now. You’re, I guess, going to that firefighting idea, going in and firefighting, trying to iron out process and agency is one challenge, but what are the challenges that, day in and day out, or a particular challenge that you’re working through right now?

Kelly Suter: Currently, I would say that among all the challenges we’re always battling, I think my main one right now is convincing in a way that’s not boring, buy-in from the team, with documentation. I mean, not to just sound like I’m selling the topic of this particular podcast, but really I think it’s hard when you have an excited client and an excited team to get full buy-in of, “Okay, we don’t have to slow down, we don’t have to lose momentum, but we do have to document.” And then templatized that documentation and just covering your bases sufficiently, you don’t have to do it, it doesn’t have to be as painstaking as it can be, but documenting enough so that if you move to a different team or you get promoted or you are in a different role, that not all logic and process is lost with that. Because, I think I have seen teams that are reinventing the wheel constantly, either with their product build or their documentation, and it’s like, they’re really over-engineering what can otherwise be templatized or just more efficient.

So I think the buy-in from a team aspect like right now I’m doing some documentation for stuff that, the latest documentation is 2014, and it’s worked for everybody, the client, it’s worked for. But, we don’t want it to be that way. And, later on, when you’re auditing, it doesn’t … It’s nice to be zipped up.

Ben Aston: Cool, so in your … You’re kind of dealing with the challenges of defining process, creating documentation, refining process, in that, as you’re doing that, is there any kind of tools that you use, what are you finding that’s kind of making your life awesome at the moment? How do you deliver that, and what do you use to do that?

Kelly Suter: Yeah, so specific to documentation, you know, or I don’t fix what’s not broken, I use Google Suite, I mean, if you have clients that do not have security or privacy issues with the information in the documentation that you’re formalizing, Google Suite, Google Docs, shared space, ability to set permissions on who can just see, who can just comment, or just internally if it’s something you’re only sharing with your team.

So you don’t have to think about version control, and later you can export in PDF and make it a formal, signable document that way. So when it comes to true, just writing the documentation, that’s what we use. InVision is a really great tool for creative checks and balances, commenting when you are putting together the creative piece of it. So that is where the designers are putting all of their designs, or wireframes, it works for both, and then you’re able to allow commenting by your client, or your stakeholder who’s reviewing it, and then it’s a really intuitive way to then annotate once designs are finalized, you can analyze in InVision and then exportation for your documentation, ’cause visuals with documentation are really beneficial. If you don’t have InVision, because that’s this suite where you kind of have to pay for it and it can get pricey, then Sketch. Sketch is a tool that I have used when I don’t have a budget to pay for something like InVision, and Sketch is a free tool by Evernote that you can use to annotate beautifully and simply. For your designs that are created, you just upload them there, put your numbers or your letters, however, you’re annotating to those designs, and work with it that way.

So, really I don’t overcomplicate it, I just need a way to import my designs, annotate them, put them into documentation, and then write the words. So those are what have worked for me when it comes to documentation.

Ben Aston: That’s cool. So, I wanted to kind of dig into a bit more around kind of going back to this kind of, your evolution as a digital project manager. Now you’re a technical PM, but I understand you’re wearing different hats, you’re a project manager, you’re a BA, you’re a business analyst, you’re a SCRUM master, how is a technical PM different from a DPM, is it the same thing? And how does wearing these different hats work for you?

Kelly Suter: That’s a really good question. I think that, well, and specific to my role here, you know, I feel really lucky because it’s unique. Here at BIW, I actually, I do both technical project management and kind of traditional. So I do live event kind of project management and I do content, course content project management, so that’s about a fourth of what I do. But the other three fourths with technical project management, I think you know, it’s gonna vary wherever you look.

You can find digital, technical, agile all of these words before project management, but you’re a project manager so what the difference would look like between truly what was a DPM role previous to this job, and then what I am right now, a TPM, I think the biggest difference is the level of understanding required behind the digital work you’re doing, so how technical is your digital work getting, not to play too much with words here, but I think when I was a digital project manager, I was really getting my hands on all of the moving parts. I think I was a bit higher level, but I knew that I needed, I knew what the content strategy was, I knew what site mapping was, wireframing, creative, and then when it came to development, I was sort of like, okay, I know that you have to audit this data, I know that you have to come up with what the data will look like as an export for your inventory, and just let me know when you’re done.

Whereas with this technical PM role, I’m way deeper in the weeds particular to development. So I still am managing the deliverables out of creative and digital strategy and QA, but when it comes to development, I may on one project be required to be closer during QA, where for all the code review and releases, I am side by side with that lead dev saying, “Okay, these are the requirements I wrote, how is it comparing to the code that you’re seeing before it gets checked off the list?” The other difference, I think I would say, is I am writing the technical requirements. Which, the closer you are to requirements, the more responsibility, so the more you’re going to need to be close when those conversations bubble up down the line.

So a digital PM, I managed those requirements, told the right people who needed to do them to get them done, and then as a TPM, I’m actually writing those. So it’s kind of like I’m further in the trenches when it comes to development.

Ben Aston: Yeah, so, okay, so those people who are kind of unfamiliar with what functional requirements are or, you know, you talking about business requirements, that’s what you’re doing, you’re doing functional requirement design, you’re doing business requirement design, and I think this is often like a bit of a sticky, confusing area to people, because there always seems to be a bit of ambiguity around, well, from a developer perspective, they can often be like, “Hey, well that’s the PM’s job,” or “That’s the business analyst’s job, that’s not my job to kind of define things.” But then on the other side, the BA or PM can say, “Hey, well, I can’t define this. Like, I don’t know what the options are.” And so, how do you, I mean, you obviously have got a role where you somehow sit in the middle here, how do you go about that process?

Kelly Suter: Right, well, I think at the beginning of any project, or when you first come on a team, or with a company for a first time, really understanding the roles and responsibilities. Because, while they may be defined, they may evolve or they may change depending on the client. There have absolutely been times where we are working with, say a custom integration, and I can say, “Okay, this integration, so it’s like an inventory, it’s a database of all these different products.” I can say “I need these to live, I need these to propagate live, and I need them to show exactly how many t-shirts are in the inventory, how many small, mediums, and larges. I need them, you know, the data to update on a daily basis at this time.”

You know, I can tell the developer what I need to happen, but they might go a level deeper that I can’t touch. And I don’t understand. So I can’t pretend to understand, I don’t want to pretend to understand. I want to sit down and say, “Okay, so I’m going to own to this point of the requirements. Can you help me out and finish, you know, asking those five why’s as something,” you know I bring up in my article, where you’re saying “Why do you need this to populate in this way. This. Because this is how often visitors are buying this product, and why, why, why.

And there’s a point where you have to draw the line and say, “Okay, dev, I need you to help to write the rest of these requirements when it comes to this function, because I can’t, and I don’t want us to risk something falling through the cracks because I don’t understand.”

So, it’s a balance. And it’s just identifying upfront what you’re able to do. I have been asked before, “Why are you doing this when we should be having the business analyst do this, or we should have the learning strategist do this,” whatever it is, and my answer to that is, “Absolutely you can ask that of your team, then you have to ask yourself, okay, how much of their budget am I willing to parse out for them to do requirements, and then I have to do checks and balances where everyone’s reviewing. Or where are you going to save more budget, where are you going to be most efficient, between you doing the requirements and someone else.” So, it’s a balance, and it’s gonna change, and people, as long as they don’t take it personally of who owns what, but we’re just really playing to each other’s strength, it’s going to work itself out. But there has to be communication around that.

Ben Aston: Yeah. So, for those people who are kind of hearing this and thinking, hold on, like, what even are, what is business requirement design or what is, what are functional requirements. They might be thinking, K and R, agency or studio, hey we just like designs and stuff, and then we hand it over to the developers and it gets built. You’re talking about making, you know, documentation. Isn’t that like the opposite of what we should be doing, we should be agile, we should be flexible?

What’s your kind of … What are these documents? Why are they important?

Kelly Suter: Yeah, so to speak specifically to business requirements documentation, when I talk about, which I’ll say BRD from now on, and then functional requirements documentation, FRD, the former, BRD, is really, you can compare it to a 101 course of a class. It’s like, the higher level bullet points sometimes of, we need this to be translated into Spanish and Mandarin. And we need to deliver 10 different courses. And we need this to be alive by April. And we need to be able to support a 6,000 user database or that amount of traffic. So that might be what your BRD consists of. It’s pretty much, “This is what we’ve talked about so far, make sure that your feet are pointed in the right direction,” and it’s kind of a formality, a checkpoint sign off for everybody on both sides to say “Okay, yeah. We’re on the same page.” But of course, there’s verbiage in there that says, “We’re going to further define this. You know, if things start to fall out of scope or creep over budget, we will let you know, we will reprioritize, we will decide what says, what goes, what gets pushed to a phase two.”

Whereas FRD is a whole nother checkpoint, and a lot happens between BRD and FRD. Because you’re taking each of those points, and more, and blowing it up into further detail, okay, we’re going to do translations into Spanish and Mandarin, then are we doing that through a third party vendor? Are we having code written where this is something more automated, are they going to manually have something in the content management system and admin where they’re going to input three different languages separately. And then you’re blowing up all of those points. So BRD, like I said, is really a checkpoint, say, “We’re all on the same page.” Knowing very well that FRD may involve, I mean it’s going to frow, definitely, but you might say, “Oh, you know what? They know now that translation is something a bit out of their reach right now, for budget. We’re going to table that for a phase two.” You’re going to document that in the FRD, and then you’re going to focus on defining everything else.

So, I think on evolves into the next and the FRD it just really your blueprint for the build, or it should be.

Ben Aston: Yeah. Okay, so yeah. So the BRD is what we define at the beginning of the project. It’s essentially defining what success looks like, from a business perspective. How is this project going to deliver success? What are the things that we need to touch on, whereas the functional requirement is where we’re defining, “Okay, for this bit of functionality, or for this business requirements, this site needs to work in, well it needs to be accessible and readable to people in China, therefore, it has to be in Mandarin, it has to be localized, and that’s kind of where we go into the details?

But, I mean, let’s kind of talk about the agile thing, and like, what’s you’re kind of take on … I think there are a lot of developers who would be, well, I think there’s two camps, aren’t there? There are some developers who are like, “Hey, show me the requirements, I can’t do anything without any requirements.” And then, sometimes when you give those same developers the requirement, they’re like, “Hey, this isn’t how we should be working, we should be agile, we should be just delivering a small piece of this functionality and iterating on it, we don’t need to create all these masses of documentation. So, how do you strike that balance of, yeah, an iterative approach and the kind of shift or more agile ways of working where we’re trying to limit the amount that documentation, we’re trying to test and learn.

And what sounds like you’re doing in these kinds of functional requirements design, where you’re kind of trying to define everything as well as possible so that, you know, there’s this shared understanding of how we deliver that business success. How do you strike that balance?

Kelly Suter: Yeah, that’s a really good question. I think that you strike that balance by having an upfront understanding, dare I say documentation, saying “Okay, we’re gonna direct them to an agile process. This is what that means. And this is what we need from the client-side, this is what we need internally,” have an internal, you know, really solid kick-off to say, “Okay, here’s the product that we’re working on.” Okay, so I’ll use an example. Right now we are building a software that associates points to learning. So you’re going through courseware, you’re doing great, you’re doing not so great, you’re making progress, there’s all of the, there’s this logic in place and it’s directly related to getting points to points to then be able to use in a market place. And so we don’t know what we don’t know.

But the client knows they want it, they want it by January. And they trust us, we’ve worked with them on a number of engagements in the past, they know we can make it happen. We don’t have, we truly don’t have the time to do all this documentation, contrary to what my heart and soul would love, but what I have to do is I have to get comfortable and say, “Okay, great. So this is our end goal.” Knowing the end goal, and without defining all of the in-betweens, without painstakingly building out all of those tasks and breaking them out into sprints, whatever. We are week by week having our stand up and saying “Okay, you’re working on badges, you’re working on certificates, you are working on leaderboard, and you are working on the shopping experience.” Me talking to a number of developers.

And we know that that’s what they work on, and with the client, you know, it’s every two weeks doing a release and presentation to the client. And we’re looking through … They know that what they’re looking at is not only rough, it’s not going to be polished on the front end, it’s truly getting the functionality in place, I mean because there’s these APIs on the back end talking about these points and how they’re, what their value is and where they link.

So I think it’s just, I mean, those stand-ups are invaluable. And, what you can do as a PM is document those stand-ups. Saying, okay, this is what we’re showing you today, we’re showing you badges as they relate to this kind of courseware. And this is what you can expect to see happen because this is what we have done in the last week. And these are the questions we may or may not have for you. Do you want this logic to be XYZ for this badge? And so on.

And so when you have that stand up with the client, were you’re showing them, and they say, “Oh, well I thought this. Or this, or this.” There’s that trust there, where things that come up as a concern for them, they can express. We can speak to, and that we can then come up with a plan for the following week. And what is the hairy part of it, but it’s so necessary, is constantly looking at that trajectory-

Ben Aston: There you go.

Kelly Suter: So, and saying, okay between now and what, when we have this finished product, how are we tracking, what maybe do we have to, certificates are not going to be a thing, we can’t do that right now, because we have to focus on, you know what I’m saying? So, I think it’s constant communication, documentation as we go along, but having that trust.

Ben Aston: Yeah, because I think one of the things that can, yeah, often, yeah just almost put a pause on a project right at the beginning is, hey, if you wait ’til everything is defined, and you’re like, okay, well, we can’t do anything without having the functional requirements defined for the entire project. That’s going to take a really long time, so I’ve, I like this idea of, “Hey, these functional requirements are important because it enables us to … ” It gives the developers definition on exactly what they need to build, it gives the client clarity of what they’re going to get, it gives QA the ability to actually know what they’re testing against, whether this kind of passes or not. And kind of evolving as you go, and it’s kind of like, do as much as you need to be able to keep the project moving.

But, yeah, obviously it’s quite time consuming, right? The process of documenting all this out. So how do you actually do that, is that something that you do in JIRA, as you’re writing a ticket, or what’s your, talk us through that workflow?

Kelly Suter: Yeah, so that’s a good question, when I have an already completed, this isn’t me being in a silo and not checking with anybody. I mean, I let the team know, I’m going to be asking questions as I go, to know either whether it has to do with best practices, or you know, we talked about this in that meeting, where did we land, if you haven’t already taken notes for it, whatever.

And when I have that finalized FRD, everyone has reviewed it, and then we put it to the client, it’s been approved. I actually, I’ve done one of two things. I’ve either, and I present it to the development team this way. Because, like you mentioned before, some developers want the requirements given to them, they want to be told exactly what are my tasks, let me know how to do them, can I estimate them, whatever. There’s another type of developer, among many, that will say, “No, don’t tell me how to do my tasks. That is not the order that I would do them.” And you can get off on a wrong foot by doing that.

So, I’ll sit in a room and say, “First, do you prefer to build these tasks out on your own or do you prefer that I do that?” More often than not, they actually, because they’ve reviewed the FRD, are okay with you building out the tasks, and I build out a task for every line item, and I do my stories by page type, so you might have a registration story, or you might have a homepage, you might have a product page. And then do sub-tasks for every line item on that page type. And I build them out that way, and then what I have the developers do, no matter what, ’cause I’m not going to estimate their time, and if you have the freedom to do this within your company, have the developers estimate their own time. Preferably who will be developing it, don’t have your best developers estimate everything and then a junior developer go in and build it, if at all possible.

And, because they’ve read the requirements and they know the expectations, there should be minimal delta of what’s estimated in line with that documentation. So I use JIRA, the Atlassian suite JIRA, for task management, and once I have everything built out in the backlog, I have them estimate it out, I tell them to order it, if they can, ballpark in the way that they’re going to tackle them. Then I break them out into sprints based on 30 hour weeks, 30-35 hour weeks, if that, if they’re single-threaded, of course. So there’s all these elements that play into it. But if you’re doing it agile, and you want a QA element to every one of those tasks, have your QA resource, or you, build a line in each of those tickets of how to test to make sure that that is either successful or not successful.

Ben Aston: Cool. So, I want to touch on something that you mentioned there, just area around estimation. And I think this is a, like as we’re doing more, increasingly technical projects, this becomes more of a challenge, right, where at the beginning of a project, a client wants to know how much the project’s gonna cost, then we have this challenge where we don’t know exactly the functionality. So how do you, I mean what you talked about there was, I guess more of an agile process, where you’re working with the clients, maybe you’ve got some kind of retainer, or you’re not having to estimate the entire project upfront because you talked about kind of estimating per requirement.

But how do you deal with that at the beginning of a project, when you’re trying to give a client an estimate for, “Hey, I think this is going to be 200k,” are you basing those on the business requirements, or how are you, what are you, how do you kind of do the pre-functional requirements to get to those early ballpark estimates to enable a project to start. And how do you balance that around then translating those kinds of ballpark estimates to the actual functional requirement designs and the estimates to that more defined piece of functionality?

Kelly Suter: That is a loaded question. I think that I mean, by all means. If I were given the power, as a PM for my projects to help give a ballpark estimate, I would say truly, 90 to 95% of the time, I do not have the power to chime in with any opinion of an estimate, if not just passing by in conversation, just like, “Hey, I’m talking to this client, and they have this really great idea, what do you think, do you think we could get it done by March?”

And it’s like, “What’s going on, what is it about?” Like, of course, me, I have a hundred and ten questions right away. But, when I do have the ability and am approached for a ballpark estimate for what something is going to take, I first want to know, just high level, what have we done before? So typically, in a company, you have some sort of specialty. People, who say that they are platform agnostic and full service and will do anything and everything, right? Like, good luck, because absolutely sales, that’s going to be really tough.

So I find out what we’ve done before, see based on the size of either their user base or the size of the company, like have a couple points of similarities to pull from, from the past, to apply. But otherwise, I mean, I do know that for example, an eCommerce build, previously, from Magento, Magento one, was just 6-8 weeks, that was kind of the default, 6-8 weeks, two developers, pretty much single, maybe double threaded. That’s how long it would take. So not hours, not dollars, but of course we had somewhat of a price point to stand around.

But what I would tell salespeople, or business development folks is truly, we don’t know, we don’t know, if it’s no integrations, no customizations, kind of out of the box, this is for our solution, this is what it’s going to be, but that’s a tough one to be able to estimate out from there, that’s what’s great about something like a development lead position, or a dev oversight who can kind of be a speaker for that department. But, sometimes that’s what the technical PM is. So, I guess, just having in your back pocket kind of that one sheet of, okay, if this has to do with eCommerce, or if this has to do with learning management system or whatever it is, that you have something to relate to. And that’s a very open-ended answer, but that’s tough.

Ben Aston: Yeah. No, I think you’re talking about analogous estimating. Yeah, the best way, early on in a project when we’re asked to give a ballpark figure, but we’re not entirely sure on the functional requirements, you’ll go and ask a dev, “Hey, how long should this take to build, yeah, an eCommerce site,” and there’s so many variables in that, so the only thing that we can do, really, is at that point, at the ballpark phase, is to say, “Hey, look, here are three projects that we did that kind of see a bit similar to what you’re talking about. Here’s the low end of that, here’s the high end of that. So maybe it’s somewhere in the middle.” And try and, at the early kind of part of the project, not committing to that number or to that estimate until we can define the requirements more fully. But kind of giving them a ballpark, and help them understand that that’s kind of part of the discovery process is defining what their requirements should be, and then as we define the requirements, then we can estimate more fully.

Kelly Suter: Yeah, and two exercises I always do, and one is … and they’re both really quick, to talk to your client about is from kickoff, I make the triangle, and scope, timeline, and budget, and I make them rate these one through three, of importance. And they’ll say, “All of them, haha ha,” and you’ll have a good laugh. And then you’re like, “But seriously. If you had to choose, an order, because that is going to determine so much.” And you know what, that might change, throughout. They might, you know, the new fiscal starts and suddenly isn’t of the biggest concern. And so, I think that that’s one exercise I do to help that conversation of the unknown, right?

And then the other, the other exercise that I do is the good, better, best. People have heard it before, where if you have this budget, you’re like, okay, great, I would love to stay within this budget as much as you would. But as you go along, if an integration pops up, or a third party vendor blows something out of scope, because their designs are just awesome, but also technically insane, that you can say, “Okay, great.” We can do this, this is what it will cost, which is over your cost, which is over your budget, or, if we’re on budget, this is what you won’t get, for scope. Or, let’s find a happy medium in between. So have a good, better, best, and make the client make that hard decision. So that you’re not just laying the hammer down and telling them, “This isn’t gonna happen.”

So those are the two exercises that I find actually the most beneficial, and in terms of keeping things within timeline, scope, and budget. But also it allows your client to truly feel like you’re letting them in on this collaboration decision and having them make that sort of business decision.

Ben Aston: Yeah, I think that’s great, I think what you’re talking bout in terms of making this a collaboration, I think often clients can sometimes kind of force us into a corner and say, “Hey, I want you to commit to a budget,” and obviously this is really tricky when it’s fixed price, and if we’re working on a really technical project with some new integrations, or a new platform or something we’re not sure about, that can be really, really tricky. So I think, I love what you’re saying about making this a collaboration with the client, helping them understand that if they’re gonna extend the functionality of something or they want something best, then it’s going to require more work. That’s the way that we can kind of tailor the estimates and tailor the approach, we can tailor the functionality based on what the client’s prioritization really is.

But like, in terms of if you’re … Just finally as we finish, just we think about, okay, someone’s listening and they’re like, oh my gosh, this sounds great, like, if I can really define with the developers upfront what they should be building, it might not be something they’ve ever done before, they might’ve just have wireframes and designs and kind of gone straight into dev, what would you say, as someone kind of dipping their toe in the water with kind of writing requirements, what’s the first step to actually getting a bit more, I guess, you know, introducing the idea of requirements and getting a bit more solid about the way that you’re kind of defining development.

Kelly Suter: Yeah, well, I think, I mean I’ve said this before when I’ve had this conversation that, if you’re in this role as a digital project manager for the first time, you being someone of this digital age, someone who’s existing right now, who is exposed to smartphones and tablets and just technology all over the place, you know more than you think you know. Because you have already been exposed to digital behavior and you’ve already learned habits, and you’ve already survived thus far in the technical age. And you’ve gained so much more than you probably realize you have.

So, rather than jumping and Googling technical documentation template and then downloading it and then trying to fill in the gaps, I may or may not have done that before. I think that you need to take a step back and “Okay, what are we doing for this client. We are building them a registration webpage for an event and it has a homepage, and you just have a web form on that home page and that’s it. What do we need to define here?” And just find every element of that page and ask yourself, “What does this do? For mobile and for desktop.” And just starting there. And pretend that you are explaining it to someone’s grandmother, who still has her Nokia brick phone, explain it out loud to yourself. And then go to your developer and say, “Am I right in assuming this?” And the developer is going to appreciate, I mean they might judge you a little, but they’re going to appreciate it, that you’re asking those questions and making sure you’re defining something in a way that’s going to allow them to be successful too when they build it.

So, I think, when you’re dipping your toe in the water that is requirements documentation, just parse it up, chunk it up into elements of what you’re building, and then explain it. And I think that if I looked at my first requirements documentation, oh, I probably, it sounds more conversational than it should, I’m sure. And I’m sure I was inconsistent with the same exact functionality on different pages. But that’s okay. It’s going to evolve. And you know what? This is a digital project for your client, this isn’t something that likely they do all the time. And so, you are representing your company or your group or your team as an expert. But just walk through it with them, and you know more than you think you know because we all live in it.

Ben Aston: Yeah, I think that’s really helpful, I’ll have to decide, yeah. I think requirements really is all about asking questions and getting questions to answers and I think, as we kind of start defining requirements, we can think, “Oh, is this a stupid question, is this obvious?” But I think understanding that actually, no, nothing really is obvious, and you can start by just asking yourself the questions, yeah, if you were going to try and explain this to your mom, I like that, or your grandmother, what would you need to tell them?

And then yeah, remembering as well that it’s just this communication tool, that it’s the piece of documentation that’s gonna enable everyone to be on the same page with what actually is being done. And I think when you’ve got clarity around what you’re actually doing, it means that it’s a lot less wasted effort in terms of expectation management, it means everyone’s on the same page with what you’re delivering, and it just means you’ve spent, you waste less time. It might take time to do it, it might take time to create, but that kind of pays back massive dividends, when you don’t end up doing rework or the client, doesn’t get disappointed because they got something different to what they’re expecting.

So, Kelly, thanks so much for joining us, it’s been great having you with us.

Kelly Suter: Thank you, I appreciate it.

Ben Aston: And, as one of our DPM experts, Kelly is also making an appearance in our Mastering Digital Project Management course, if you’re not sure what I’m talking about, but you know you need some PM training, check it out. We’ve got a seven week crash course, it includes some interactive video lessons, assignments, group discussions, webinars, head to dpmschool.com and get yourself signed up, our course starts in February, and if you’d like to contribute to this conversation, about requirements, how we do it, head to the resources section of thedigitalprojectmanager.com to join our Slack team where you’ll find all kinds of interesting conversations going on there, or just comment on the post. But until next time, thanks for listening.