Gerir a Construção de um Portal Web (com Rebecca Germond da FCV Interactive)

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.

Client needs are maturing, and the role of digital agencies is changing and evolving too. As the website design and build process has become more commoditized, there’s this growing need for agencies who can be more than just a website partner but can be a strategic and technical partner too to build not just websites and campaigns and landing pages. In today’s podcast, we’re going to nerd out a bit on portal builds, what they are, how you build them, and some takeaways and lessons learned if you’re going to embark on one of these projects. Keep listening if you want to get the low down on the evolution of digital agencies and a product development approach to client engagement.

Today I’m joined by Rebecca Germond. Rebecca is the director of client services at FCV. She’s got a strong foundation in project management and media communications. Rebecca is actually someone that I hired a few years ago. I remember your interview where I brought you in the room and I was like, yeah, sure, I’ll hire this girl. I don’t really remember what I asked you, but I was like, I don’t even need to interview you. You’re hired. Do you remember the interview?

Rebecca Germond:

I remember the interview. I felt like I was grilled. No, I’m just kidding. I’m kidding. I remember it really well because I remember the view from the office and that was what sold me, I think, on FCV, and of course our conversation.

Ben Aston:

It wasn’t me. It was the view.

Rebecca Germond:

Yeah.

Ben Aston:

Rebecca, for those who are wondering what you do every day, what is director of client services about? Is it project management? Is it account management? What does that mean for you right now?

Rebecca Germond:

Yeah, it’s a bit of both, plus managing the actual PM team, which it’s cool. It’s a new role for me over the last year or so. I don’t get my hands as dirty with projects as much anymore. There are a few that I won’t let go of, but really I get to work directly with the PMs and make sure that they’re able to deliver and give them the support they need. As well, I manage most of our clients, so I have a pretty good account manage-y relationship with them. Actually, I started in accounts before I became a producer project manager, so a little bit back to my roots, which is cool.

Ben Aston:

Nice. For those who are interested in this role of managing a team of project managers. Day in and day out, what does that look like? How do you manage them? Because you can’t be in the details of all their projects all the time. When you’re checking in with them, what do you actually do?

Rebecca Germond:

Yeah, that’s great. What I do is for the most part, I just review a lot of work or deliverables that they want to send. For example, I will give them feedback on an SoW or a timeline. If there’s any ever escalations, I get involved or I help the PMs navigate how to respond to any sticky situations. I meet with them on a one-on-one basis weekly, but then I also connect over Slack and just make sure everybody feels supported on a day-to-day basis. Occasionally, I’ll come and join their more important client meetings. It’s just a little bit of of that.

As well, I’m heavily involved in our business development process at FCV. I also work on the day-to-day with how much are we actually going to invoice our clients, and are we making sure we’re keeping track of our change management process enough? A lot of other things in just the day in, day out with the PMs as well.

Ben Aston:

Tell us a bit about your story. Your background was in account management. Actually, I know you started off your career in the Ministry of Labor. How did you get from the Ministry of Labor to digital agency and account management, project management? What did that look like for you?

Rebecca Germond:

Totally. When I was in school, my aunt has a temp agency. She would place me with jobs when I was trying to find the right place. I knew I wanted to work in an agency. I did get a placement with the Ministry of Labor. It was more like an admin job for the government, but it was pretty cool. It made me learn a lot of ins and outs for the government, which actually helps me later on in my career because most of the projects that I worked on at my first agency, and now a lot of the projects I’m working on now at FCV, are government-related. It was helpful.

One time, she got me placed at an agency, Manifest Communications in Toronto. I was only to do a two-week temp front desk work while someone was on vacation, and they asked me to stay on for an internship, which is what I was trying to nail anyways. I did that for three months, and then they hired me on, and I worked there for four years. When I first started, I was an account executive, so I was managing clients and less so digital projects. We slowly moved into that. After my first year, I became a producer, and it would probably be about 60% digital, but then I also got to work on radio and broadcast and some print stuff too, which was pretty cool.

Ben Aston:

Nice. Tell me. We’re still in the first quarter of the year. From your career Korea perspective or growth perspective, we’re talking today about portals and how that’s a bit of an evolution, but have you got any goals that you set yourself for the year?

Rebecca Germond:

Actually, it’s funny. I don’t really want to have any specific career goals this year. It sounds weird. I’m in my last year of my 20s, so I really just want to live like a Millennial. I have some travel goals. That’s what’s up for me. Really in terms of career, I’ve loved working on this portal project. We’ve turned it into a product, and we are constantly doing releases and trying to build on something. I think it’s really great. I would love to do more work like that.

Ben Aston:

Cool. We talked about a bit about what your role is in terms of what you do, but what are the challenges that you maybe are dealing with right now or what’s your biggest headache that you’re trying to overcome on a day-to-day basis or particularly now with a particular project or something?

Rebecca Germond:

I think on a day-to-day basis for me, I’m used to babysitting in a project team environment, if you know what I mean. We all are, as project managers, we have to deal with a lot of egos or just different personality types. Now I think on the scale where it’s less projects and it’s actually everyone throughout the organization has different needs and everyone has different priorities and just trying to juggle that with as well making sure to let the PMs have what they need because that’s super important. I find that’s just a bit difficult. As well, you get wrapped into things that you maybe don’t think are such a big deal like admin stuff. I don’t know. It’s just trying to keep track of my own to-do list is a struggle these days.

Ben Aston:

How do you keep track of things? What is your to-do list like? Have you got a system?

Rebecca Germond:

I use most of my to-do list in Evernote, but we’ve just added a new Slack integration called Workast, which you can keep your to-do list in an actual Slack channel and then assign things to them if you need. You can also just write a note to yourself in Slack and your to-do list is there, and it’ll give you a reminder about when things are due. We’re really early on using it, but so far, it’s pretty cool.

Ben Aston:

That’s called Workast?

Rebecca Germond:

Workast, W-O-R-K-A-S-T.

Ben Aston:

Workast, okay. A bit of a funny name, Workast.

Rebecca Germond:

Definitely. So far, so good. The problem is you don’t get to your to-do list until either before 9:00 or after 5 PM. That’s how I feel because everyone … 70% of my day is either meetings on the phone or responding to emails in Slack, which makes it really hard to be productive these days.

Ben Aston:

What else is in your PM toolkit? You’re on your to-do list system, which is obviously helping you prioritize the really important stuff. What else is in your toolkit? How do you manage projects?

Rebecca Germond:

I’ve got quite a few tools. We’ve, I would say, flipped back and forth on a few over the last couple of years where we work and now I’m pretty happy with what we’ve got. Like I said, I used Evernote. We use Jira pretty seriously now. Everybody, including our UX and design and all of our clients, are in Jira, which makes it easier for us because everything is at least in one spot and we can keep track of tickets. We use Slack. I use that pretty religiously.

Microsoft Teams, we’re testing out instead of Skype for Business. We’re just using it in a conference line setting for our meetings with clients. It’s been working out pretty well. I use Merlin for project scheduling. We used use MS Project, but I just find we’re only using 15% of its capabilities. We keep a couple of MS Project licenses floating around just in case the client needs it. Spotify, that’s definitely in my toolkit. I need that. I guess Outlook, although email is the bane of my existence.

Ben Aston:

Apart from Workast, are there any other tools that you’ve come across recently or things that have revolutionized the way that you manage projects?

Rebecca Germond:

Not really. I think the way that we’ve now used Jira, actually we’re integrating, we’re using integrations in our Slack channel. If a ticket is updated, the status is changed. If a client comments on it, obviously Jira sends you 40 emails a minute when something is updated. Only the key things are sent to the Slack channel so you know if someone has made a comment on a ticket. That’s really made it easy because no one is reading Jira emails. MS Teams is actually pretty cool because most of our clients didn’t want to use video, but now there’s a lot of them that have taken it on from when we’ve moved over to MS Teams.

Ben Aston:

Nice. Cool. Let’s talk about your post, your case study, the first case study you have ever published. Congratulations, Rebecca.

Rebecca Germond:

Thank you.

Ben Aston:

Let’s talk about a portal. Is a portal just a website or is it different? If it is different, why and how is it different?

Rebecca Germond:

For me, I think portals are pretty complex because they’re generally tailored to a lot of different users, which all of those different users may have many actions or features or journeys for each. For this particular portal, there was three different user levels that we needed to keep in mind, and how they would impact one another was something that I think we underestimated at first. I think for portals in general, they can get pretty complex just because of all of the different ins and outs that may not be something that you would just get on a regular website if you just hit it and check out the homepage.

Ben Aston:

What we’re talking about is something where there’s richer interactivity in terms of role-based functionality that is either enabled or disabled depending on what you’re doing in the portal.

Rebecca Germond:

Exactly. For our portal in particular, unless you had a login, you’re getting not getting much from the homepage. There are some barriers in place, and it’s not necessarily easy to onboard new clients into the portal. There’s a lot of things to keep in mind that just don’t apply to a regular website.

Ben Aston:

Interesting. So we’re not talking in abstract, give us a brief overview of the functionality of what this portal is.

Rebecca Germond:

Perfect. This portal … Basically our client, I’ll give you a little background, they’re an electronics retailer, and they have B2B clients so businesses who like to order products from them in bulk. Prior to having any portal environment, they were basically picking up the phone and calling their account manager and placing an order really, really, really manually. It was giving everybody headaches. It was giving the clients headaches because no one wants to pick up the phone anymore. What they were looking for was some portal where people can log in, people can see a catalog of products that’s been assigned to them and only be able to shop from those products. As well, there’s a complicated discount mechanism applied on them because if we didn’t have the portal and we didn’t have this discount, people could just go shop with their consumer website and buy what they needed. Because they’re buying in bulk, they’re getting pretty tailored discounts based on how much they buy and what they do. That’s one aspect.

We also have a checkout. We have a dashboard where people can see their most frequently ordered products. They can see open orders that they have, anything that’s been placed in the last 30 days. There are some cool tools on the dashboard to help make them see what’s going on in their world on the portal.

As well, there’s a few different user levels within who can just shop. Most of the clients can go in and place an order, but then you would need a client admin to approve it depending on their organization. That’s before an order goes through, people need to be able to approve it or let them know, sorry, you’re exceeding our budget so we can’t put this order through. There’s a lot of ins and outs there as well.

Ben Aston:

Interesting. Essentially this is, say I’m a large organization. I’m Telus, and I want to order 2,000 new monitors or something. I just log into the system, buy my monitors, but then there’s an approval checkout process thing as well, and then I can track my order.

Rebecca Germond:

Yeah, exactly.

Ben Aston:

It’s eCommerce at scale.

Rebecca Germond:

Yeah, exactly.

Ben Aston:

Cool. In the post, you talked a bit about using some interesting tech. I’m wondering if you can give us the Coles Notes on the tech stack, the architecture and what the solution is, like how you actually build this. What made it interesting?

Rebecca Germond:

Cool. Definitely our devs could speak to it a little bit better, but I can give us a little high overview.

Ben Aston:

The PM version.

Rebecca Germond:

Yeah. What we’re doing is we’re using .NET Core to power microservices, and then we use React on the front-end to actually provide the interfaces of those microservices. Basically, what we mean is those microservices are just end points so you can reuse them in any way you want. For example, you’re getting data from the volume of orders. Just because we have that information, that’s how we can spit it out on the dashboard or we can manipulate this data in many, many different ways, which is really cool. Obviously, React is really exciting for our front-end developers, and they really like working on it. When we used React, we created a component library that we could leverage, so different areas of the site so we didn’t have to constantly rebuild the same components. As well, we wanted to provide a really consistent look and feel throughout the site and something that was still on brand to them and didn’t feel too much of a departure from their consumer website.

Ben Aston:

Cool. There is no CMS. How was that process? Within .NET, you’ve created the functionality for I guess the retailer to be able to add products and edit products. Is there a CMS for that side of it? How does that go?

Rebecca Germond:

No. The beautiful thing is all of the product information or product data is coming from a client’s provided API that they use on their consumer websites. All of that product information is updated all the time. We have a script or something that is running once a day to just make sure that we’re getting the most up-to-date price and the most up-to-date product information on specs and that kind of stuff as well. It’s a completely automated process when it comes to adding a new product, which is pretty cool.

Ben Aston:

That’s cool. This was product development, building out a portal. That was something new. Tell me how you planned out the project or the product development. What was your process for trying to plan out this build?

Rebecca Germond:

Definitely we took an MVP approach, minimum viable product, which worked and didn’t because I feel as the project went on, what became the MVP kept growing. It wasn’t really minimum at all. At the start and when we really planned out the timeline and the estimate, the MVP approach helped us quite a bit. Because we had a pretty defined backlog, we jumped right into development sprints. We didn’t take it too long of a requirements gathering with this project. What we would do was we would tackle the requirements in a sprint planning meeting for the features that we were going to attempt to complete during that sprint.

Ben Aston:

In terms of the MVP, was there a budget and a deadline for the MVP? You’ve got a backlog of stuff to build. How are you working out what’s within budget and what’s out the budget? At what point did you define the budget for that? Because I think that’s one of the big challenges here.

Rebecca Germond:

It was. It really was because … I think the hard thing with working agile in an agency setting is the clients want to see a price for everything. True agile is maybe a cost per sprint model. At the end of a sprint, you might not have a complete feature. The way we had to attempt to tackle the estimate was give them more of a la carte per feature so they knew exactly how much a specific feature would cost so they could prioritize them themselves if needed. Some of those features were dependent on others. Once we figured exactly what came in the MVP, that’s how we determined the cost and exactly what we had to do in order for all of those dependencies to work out as well.Based on that cost by a la carte pricing, we tried to bulk it up a bit so it could work in a sprint model. We knew we had five months to complete the project with a month of UAT at the end. I think we did two weeks of just environment setup and that kind of thing. I think we had six or seven sprints total.

Ben Aston:

One of the things that you mentioned in the case study is that you massively underestimated some of the mandatory features, but you said that’s what made it fun. What I’m reading in between the lines, and you did this a la carte, but you underestimated some of those a la carte items. How and why were they underestimated do you think?

Rebecca Germond:

I think the biggest one that we underestimated was the actual catalog building and then applying the discount on top. For us, we were like, oh yeah, we’re just adding a discount to specific products. When you get into the nitty-gritty of their API and all of the different categories of products, they have all the different facets. That logic coupled with a discount on top of it got really, really, really complicated. There was another layer to it where they wanted to actually exclude some products. For example, Apple, they didn’t make a huge markup on it, so they would never want to discount an Apple product. We had to make sure that if they said exclude brand Apple from this, then you would only surface products with these characteristics and not Apple plus add the discount on top. It got really, really confusing and complicated.

Unfortunately, with this client, it was more of a fixed price engagement. Where we were able to make our money back or get time as well was with a lot of change requests that they added along the way or even change request to features that were included in the a la carte. We did our best when needed to keep on top of that change management process. When it comes to just ourselves underestimating, it’s really hard to go back to the client and say, sorry, we didn’t exactly do our job right.

Ben Aston:

Part of that though is the fact that the requirements, it sounds like some of the complexity around some of the discounting might not have been clear right from the start. Right?

Rebecca Germond:

Exactly. I think when we did those, the initial requirements, the discount engine or whatever it was we were building was supposed to be a lot less involved. It just got a little bit hairy once we dug in a little bit more.

Ben Aston:

I think this is often the case though with more agile projects where the whole point of running a project in a more agile manner is that it suits a scenario when, hey, things aren’t entirely black and white, but then it needs a cost model to reflect that. Obviously, here you’re working with a fixed price and unclear requirements. Based on what you know now, how would you plan it differently next time?

Rebecca Germond:

I think we did a good job with the requirements that we had. I think what I’d like to attempt with this client … and we have an awesome working relationship now. He gets it, and he’s really just an extension of our team, which makes things super, super helpful. We’re trying to sell things in a more cost per sprint model where we’re not really getting there, but we are able to we have a lot of ability to wiggle with the timeline with him, and he’s just really understanding, which is great. If we were to start this over again next time, I think maybe even if we could give them a rough ballpark at the beginning because what they need is they need to be able to get some number approved.

If we give them a good range and then during each sprint, we could more estimate what we’re going to tackle in that sprint and give them a price per sprint depending on how many team members we needed and what we were hoping to get done, that might be better. Overall, I wouldn’t change much about how we operated on the team. I liked how lean we were. I liked how a few of us there was. It gets difficult if there’s a lot of people involved on the client side. It was really just him and the appropriate stakeholder that needed to be involved for whatever feature we were tackling in the sprint. That was very cool as well.

Ben Aston:

Cool. You’re talking about a small team there and that was one of the things that worked well. In your post, you talked about this hybrid agile approach to development and design. Can you tell me what that actually looks like in terms of who was on the team? This is a small team. How did you make that design development thing work?

Rebecca Germond:

Yeah, it’s difficult. I think in agency setting in general, it’s really, really difficult to go full agile. At least, I find it is because clients are not really open to paying for a team for five months straight. They want to know what the feature is going to cost. They’re not really selling a team. It’s hard to change that perspective. If you’re in-house and you’re building your own product and you have dedicated people to be involved, whatever, eight hours a day, five days a week, then it’s a little bit different. When you have multiple projects involved, it’s really, really, really hard to work in agile.

What our team looked like and how we had a hybrid approach, we had two back-end, two front-end, a halftime UX, and a designer who probably came in once in a while just to vet our creative or our features, and then one QA, which would also generally be working halftime during the sprint, like 50% dedicated. We didn’t use a BA, which I still think is okay. I don’t think it was really to our detriment because we knew what we were building. I don’t think really a BA would have been able to tell us the ins and outs of their API or anything like that. I don’t think that would have helped us with actually the estimation process. I think that that helped us. We didn’t have a strategist involved because the product was really cut and dry, and the client had a pretty well-defined vision for the MVP, and there was a strong use case behind it, of course. That was the team. Me, of course.

How we approached it? Because we’re starting from scratch, we had no components already built for this. We basically just had brand guideline to use to go for anything that they wanted and then the feature. We had design and UX actually working a sprint above, like in front of, ahead of the dev team, which I think in a true agile, you wouldn’t really get that. You would try and deliver a feature together, but the client had never seen anything we had ever done before, so we really needed to give them a little bit of a headstart to make sure that we were on the right track with look and feel and that kind of stuff.

We used that first sprint where design and UX were working ahead for our environment setup and anything that we needed to get because it was a brand new deployment pipeline we needed and all of these project setup things that the devs needed to tackle. On the other hand, our client’s organization does work agile or they tried to internally. It wasn’t hard for them to grasp, and they really enjoyed the working style. When it came to all of the agile ceremonies like that stuff that we still tackled for sure, things like scrums, mid-sprint reviews, demos, retrospectives, we all took it pretty seriously and the client joined all or most of them.

Ben Aston:

Nice. Let’s talk about the client here. The great thing about this scenario was that the client, they were the product manager, right? You didn’t have a whole bunch of stakeholders. You had a single stakeholder, which is cool. You mentioned they were great, but also you said in your post that the client dreamt up some new features and tasks along the way. When you’re working with this fixed budget but an agile approach where it’s totally fair for them to dream up new features and tasks, how did you manage that?

Rebecca Germond:

It was definitely difficult, but anytime he would dream up a new feature, he would understand that it’s a CR and that we needed to quote on it. The problem was it made it pretty difficult to stop work from what you’re doing on the sprint and get them an estimate because they need the estimate in order to approve the feature, so it made things a little interesting. The client in general, yeah, he was being the product owner I would say, and his team gave him full autonomy of how to run the project and work on it. I think they were planning it for quite some time before we came on board. It was really good that they brought us in when they did because we were able to give them feedback and ideas on new features and things that they hadn’t really considered.

He definitely had some fun features to bring to the table in the middle of nowhere, but they were all things that were super, super important. For example, I think prior to the build, they were still anticipating to manually onboard these clients. Send them a PDF with information on signing up and that stuff. What we decided probably after the third sprint was we wanted to do some setup wizard so people can actually come in, get a login and password from an email that we send them. They can come on, reset their password. They can download all of the forms that they needed to fill out and re-upload them to the system. It made it a little bit easier for their team to manage. Although, we weren’t really anticipating it, it made the overall products pretty awesome.

Ben Aston:

That’s cool. You talked about obviously some of the lessons learned. One of the things you said was keep your team engaged and your client involved. It sounds like the client was really involved. What would your tips be for maintaining and driving that engagement in the first place?

Rebecca Germond:

I think for us as well, the whole working style, the way we’ve attempted this is new for FCV because a lot of our clients are legacy clients or government clients. They’ve been working with us for years and years and years, but they are stuck in their ways. The way we got our client engaged and involved actually paid off really well because we saw that clients actually want to be involved like this at this level. It was really interesting. Also, we wanted him to be engaged because we wanted there to be a phase two of this project. We really wanted to continue this. We saw that it’s not just a website that has an end at the end of its lifecycle. This is a living, breathing thing. Keeping him engaged that way was good.

Keeping the team engaged. They really wanted to work on this because they got to pick their tech stack. They got to do something new. They got to pick their own tools. They also enjoyed having a platform to speak to the client, which some people wouldn’t. It depends on your team, but we’ve got our client in Slack. He’s able to just bounce ideas off our front-end developer or whoever needs to be there, so it works well. I think they’re engaged that way because they’re building something they actually really, really care about.

Ben Aston:

One of the things you talked about was, in terms of your lessons learned, were shedding processes you don’t need but embracing the ones you do. You talked about the fact that one of the benefits of the project was the refinement it had on the project process in the agency. Can you tell me about any process that you dropped or any of that refinement that you are able to integrate them back into other projects?

Rebecca Germond:

Yeah, for sure. I think after our second sprint retrospective, we decided against doing them. We’re like, all right, we know what we’re doing well and what we’re not. Taking the time to do this now isn’t really helping. It’s just pulling time away from dev, which is not what we wanted. As well, because our client was so involved, he could give us that feedback throughout if something wasn’t working for him or we should adapt our process or think about something for the next sprint. That one is something that we shadowed pretty early.

Also, it was really difficult for us to do scrums because half of our team was in Toronto and half of them are in Vancouver, so it makes things hard. We really tried to honor the fact that to unblock people, it’s better to just jump on a 15-minute scrum than try and do it via Slack for an hour.

Ben Aston:

You just had the random scrums, were not a daily 9 AM, 12 PM ceremony. They were just ad hoc.

Rebecca Germond:

Yeah, it was 9:30. We tried to make it work, but once we got into a groove, then it would just be ad hoc or just jumping into Slack and asking some questions. We probably kept it up for three sprints, doing our scrums daily, but then we went to either every other day or via Slack.

Ben Aston:

Cool. Is there any process that you tried dropping because you’re like, hey, we don’t need this, but then you added back in after realizing that that was a bad idea?

Rebecca Germond:

Not really, but I know one of the processes that we wish we got, just general that we wish we got involved on sooner was having QA. We really didn’t have anything until the third sprint that was ready for QA, and we probably should have got that started a little bit sooner. I remember there was a couple of demos there we’re just working to five minutes before and committed some code and you’re just hoping it sticks and hoping it works. We were working like cowboys at the end of it, but it was really fun.

Ben Aston:

Good stuff. Well, Rebecca, thank you so much for joining us. It’s been great having you with us.

Rebecca Germond:

Thank you. Anytime.

Ben Aston:

Pleasure. If you’re interested in portal builds, check out the case study that Rebecca has written up. There’s a load of information in there that you might find helpful. If you want to chat about portal builds, well, head as well to our Slack team. Go to the digitalprojectmanager.com/slack, and you’ll find all kinds of interesting conversations going on there about all things digital PM. I’d also like just to say if you enjoyed today’s show, please go to Apple podcasts, formally known as iTunes, or you can go there and leave a review. We’d really love your feedback, and ratings and reviews are really helpful and it’ll help us at the show. Until next time, thanks for listening.