Everyone. Thanks for joining us today on our next ENO8 answers. We, I think we have a really interesting topic today that we get asked about a whole lot and we find ourselves in a situation a lot where we’re giving input on, on the topic that we chose for today. This is the question that we’re gonna talk about is, is your software project off the rails and we’re gonna offer five things that you can do now to try to fix that and get it back on track.
So, we’ll start with just a little bit of background on me for those of you that are not familiar.
my name is Jeff Francis.
I’m one of the co-founders of ENO8.
We’re a 5000 digital innovation studio based here in the Dallas Texas area.
And, you know, I’ve, I’ve personally helped over 100 startups quite a few more than that with launching their new digital products.
So it could be new applications, mobile applications, any kind of custom software, and worked a lot with founders, a lot of startups that have tried to launch the initial product.
And also to, we’ve done a lot of work with, with companies that are working on just building their own product internally.
larger companies that are building something new or reimagining something.
I’ve done a lot of that stuff in the past too.
So I’ve seen a lot of projects in my time and I’m excited today to kind of talk about some of the things that I’ve learned that hopefully will help you.
You all a lot with the the initiatives that you’re working on.
So let’s dive right in.
the, the, the first thing that you can do is focusing on defining and really communicating the scope.
The, this one, I’ll put it first because so many times our, our, our problems that we see in projects is it, it, it, it has something to do with scope either.
It’s not well enough to find.
perhaps different stakeholders aren’t all on the same page as to what that is.
But you would be surprised how many times there’s a project that we get asked to get involved with and we start asking questions about, well, like, like what is the scope?
What is the definition of done?
Right?
And so some phrases that you’ll hear is that, you know, we talked about this, right?
So conversations don’t equal scope and that confuses a lot of people because a lot of times people’s expectations are built around meetings that had been taking place in the past or conversations that had been in the past and assume that that’s gonna be a part of it.
And so what I find is that step number one is you need to make sure that there’s some document asset artifact that is used to align scope among all the different stakeholders.
And this could be technical people, this could be testing people, this could be business folks, this could so this could be different stakeholders that have a stake in the product success.
And so what, what does that look like?
You know, in the old waterfall development days, it was a really lengthy detailed spec document.
I’m not a huge fan of those.
I find that that so much effort is put into those and by the time that you actually start working on something, they’re largely out of date or inaccurate and people don’t look at them anyway, is it you’d be surprised to know?
So sometimes what I like to do is have a at least a high level scope document that is that is intended to be sort of feature or epic level scope that helps define like at least the broad buckets.
And then you can support that with something else that’s maybe more defined like sets of user stories or test cases or one of my personal favorites is a design prototype.
The reason why I like a design prototype as a definition of requirements is because it’s very easy for all the different variety of stakeholders to all look at that.
No, yes, this is this is what we want and if it looks like this, when we build it, that’s done, right?
And so I I find that the the design prototype, something like a Sigma prototype or envision or Adobe X D, something like that.
Those are terrific with helping to bring clarity to what is actually going to be built.
What is the definition of dot right?
So that’s, that’s the first one.
And, and by the way, guys, as we’re going through this, if you have questions, feel free to throw those in the chat, I’ll try to pick those up kind of as we go through if some of those come in.
And then I can also, I think we had a list of questions that some folks that were not gonna be able to join today had submitted and asked us to answer so that they can look at the recording later.
So feel free to drop those in.
So the next question is beyond defining your scope, right?
Defining what actually has to be built is what, what I’m saying is check your premise, right?
And what I mean by this is a lot of times we set down a path in building a product and we use a certain set of assumptions where there was a certain premise that we based a lot of our decisions and our effort on 11 analogy that I like to use for this is, is, are we leaning our ladder against the right wall?
And what I mean by that is what good does it do to climb a ladder and get to the top if you find out that it was leaned against the wrong wall the whole time.
And so some ways that this has played out that I’ve seen in the past is sometimes a decision was made on a technical approach, right?
Or the way that a particular workflow needed to function within the product, right?
And once you make a decision and you plow ahead into a project, it’s really easy to get very focused on just doing what the project plan was that you had kind of decided on all to find out that it’s really flawed and you’re gonna burn a lot of energy, you’re gonna burn a lot of time, you’re gonna burn a lot of money, try to make it work when you need to back up, revisit your premise and make sure that that your direction is correct, right?
And another example that I’ve seen this come up and is, is oftentimes when you’re happy to make decisions on build versus buy, it’s very common in building new software that, that you will build a lot of it totally custom, but you might also use certain components or libraries or pieces even other third party products that would that would become a part of that, that product offering.
Right.
And so, we, we saw a project several years ago where prior to us getting involved, a decision had been made on a product that would really serve as a pretty big core piece of the overall platform.
And It involved a lot of customization and trying to make things work.
So the product wasn’t quite gonna get 100% of the feature coverage that they needed.
And they, they were gonna try to cover that gap by custom coding around it.
And there were some limitations in the product that didn’t really get flushed out till pretty late in the project where a lot of effort just kept getting applied, a lot of money kept getting spent.
And the, it just felt like the, the effort wasn’t getting any closer to being complete.
And ultimately, in that, that situation, we had to check the premise and decide this isn’t even the right path.
And so, they had to, to go a different route in terms of how they achieve some of that underlying functionality.
But the sooner that you can revisit your premise, make sure that all of your assumptions and the information and your criteria for making that decision or that that approach still stand intact, then that’s gonna help you make sure that you’re covering one thing that, that plagues a lot of projects.
So that’s question or, or step number two, step number three, assess roles and skills.
And what we’re talking about here is the roles and skills of the people involved in the project, right?
Sometimes it takes some brutal honesty to just ask yourself, do we really have the right team assembled here to be successful?
And so, I kind of think about this in a couple of different buckets, right?
One is, do we have the right roles and responsibilities represented on our current team or is that just a gap and then two do within those roles, do we have the right person covering that role?
Right.
And so let’s talk about some examples of like, what does that look like?
You know, a lot of basic roles that you’ll see on a typical product team would be that you would have some sort of a project manager, Scrum master, right?
That, that’s sort of running the ceremonies.
You might have a technical lead that could be like an architect or that could be like a lead developer.
That’s really sort of the lead technical resource you could have supporting developers, you could have a designer, you could have a design strategist, you can have a test engineer, Q A engineer.
And then there’s several other different roles you may have des.
Right.
So, regardless of how big the product effort is, how big the team is, or how small the team is.
The different things that these roles do have to be covered by someone.
Now, if it’s a large enough effort, you may have to have a different person for every different one of those roles.
Sometimes on smaller product teams, you’ll see some of those roles get sort of clubbed together.
Right.
Right.
So, for instance, you, I, it wouldn’t be uncommon to see on a small product team for you to see the architect is also covering de hops, right?
That might be like, like, like something that happens a lot of times, right?
You might have, like the product owner kind of covering some of the Scrum Master responsibilities.
I don’t think that’s a fantastic idea, but sometimes in a small enough effort, that’s something that you can make work.
I’ve even seen where you can have a tech lead, run the Scrum master responsibilities again, not my favorite option.
But when you, when you’re small and you’re more lean, sometimes I’ve, I’ve seen people make that work, right.
So two steps to this, identify, do I have the different roles like covered and then the way that I’m covering that and who I’m covering that role with those people have the capabilities and the skill set to actually cover those.
So that’s sort of the second part of this is I’ve got all the roles covered, but do I have the right people covering these?
So how do you know, One is just, do they have experience covering that role?
That’s a really quick way to understand whether they’re gonna be the right one for that or not?
Secondly, is, are they getting results?
Like, are we, are we clear about what is expected for that role to contribute to the overall effort, Has that been communicated to them?
And we’re still not getting that, that could be a really big red flag, right?
So, others would be, you know, have they, how, how many other projects have they done that specific role or combination of roles and have they been successful there?
Right.
So if you’ve got some questions or concerns about that being a fit, then maybe a first place to start would be to just communicate, ask some questions, talk to the person, right?
Make sure they’re clear about what the role is.
Talk to the team, you’d be surprised what you can learn by just having a group conversation, identifying what’s working, what’s not working, where do we think the holes are?
And then just listen because you’ll be surprised the insights that you can, you can kind of tease out of that conversation if you’ll ask good questions and just listen to the input that’s coming from the various people on the team that are really down in the weeds working on the project.
So, in fact, one other thing I’m thinking about now that I’ll mention that kind of goes back to this, you know, check your premise.
point is one of the great ways to check your premise is to talk to the team, right?
And efforts that I’ve seen, it’s, it’s impossible to really understand what truly are the obstacles and the details of where people are running into problems and limitations unless you really, I talk to them and let them you know, speak their mind and, and, and dig into it and be curious to understand what they’re kind of seeing.
So that kind of goes together with assessing roles and skills.
So do you, do you have the right team working on this?
Next is check your expectations.
So, you know, you’d be surprised how many times a project is not quote going well or it’s off the rails or discover that really, it’s just a misalignment of expectations, certain stakeholders, their expectations would indicate that the project is going great, other stakeholders that have different sets of expectations, believe it’s a disaster, right?
And so checking your expectations as a team and making sure that you’re all aligned on that.
First is a great place to to check in on things.
And so checking those expectations can include, you know, what do we, what do we expect to be the scope?
What is the timeline that we expect to, to start seeing this completed.
if there’s milestones or checkpoints, what are the expectations around that?
What’s the expectation on budget?
Right?
That’s always a really important one.
So you also to examining like, where do these expectations come from?
Right?
Are they, are they even realistic?
You know, so some of the times when I see projects that are, that are floundering, it’s because they really haven’t been very honest with themselves and realistic about like, is this even possible or is this a realistic expectation?
So let me give you an example a lot of times this, this is classic.
So if you’ve dealt with a lot of custom software projects or some sort of a digital product launch, you, you, you probably are talking to a development team and you’re hearing like, you know, we’re 80% done or we’re 90% done, right?
And so one of your first questions needs to be like, well, how did you come up with that number?
Right, because I find that oftentimes it’s sort of just made up.
So like at least if you can look at where that number came from, you can start to understand, can I really trust that or not?
Right.
And then beyond that, have you accounted for the other things that are frequently overlooked?
So for example, when the developer says we’re 80% done, does that mean that we’re 80% done with just feature development.
Well, that’s not 80% done of launching the product, right?
Because they’re looking at what are the features we got to implement and I’ve got 80% of them almost done.
Right.
Well, you have to account for other things that very frequently get overlooked.
Like, OK once we are feature complete, meaning we’ve developed all of the features and those are in, you’re not done.
What you still have to do is you have to do AAA certain process that you’ve decided on to help test and make sure you’re ready to launch, right?
So for example, you may decide, OK, once we have the features in, we’re gonna, we’re gonna call this feature complete and we’re gonna go into a testing cycle, right?
So that could be maybe some round of what we call like a U A T like user acceptance testing or someone from your test, maybe the Q A engineer or the testing lead, they have test cases or a regression testing plan or they have a AAA comprehensive test plan that they want to run through once your feature complete, right?
And so you’re gonna have to allow yourself some time to do some thorough testing and that’s definitely gonna result in issues and bugs and questions that come up, they’re gonna need to be addressed, right?
If you’re really lucky, maybe those are super small and minor.
More likely there’s some things that are gonna be pretty chunky in there that you’re gonna have to look at and understand and give yourself some space to be able to address, right.
So build in time for user acceptance testing, build time in for your your test plan execution, build in time for getting feedback from the stakeholders.
Potentially some new scope might come in at that, that point as well.
You might discover some things as you’re going through your U A T that you just got wrong.
You know, it’s not that the developer is messed up.
It’s just that the feature just doesn’t quite work the way that you thought it should and you may need to make some adjustments, right?
So build that time in, give yourself some buffer in order to account for things that going to be inevitable.
If you don’t, you will always be late and you’ll never be able to satisfy your, your team because you’re always gonna be running behind.
So check your expectations, check your expectations as a team, check your expectations with the stakeholders.
Next and our, our, our, our, our final step that we’ll cover today is check your process stickiness.
And so what I mean by this is just check two things.
Basically, one is, are you even following a process, right?
If you’re not automatically a big problem, next is maybe you’re saying that you’re sticking to a process, but are you actually following that process and being disciplined about sticking to it, the best processes out there don’t do any good if you don’t actually follow them.
So, two elements about that that you need to check.
I’m a big fan of Scrum.
That’s what we typically use at N O A.
It works really well for us.
There’s a lot of people out there that, that are in situations, more water still works better.
Right.
I, I, I really kind of think a lot of times the process matters less than making sure you follow it.
Right.
And so even if you’re a waterfall, person, then, you know, make sure that you’re following the process steps, but in the case of Scrum, you know, really making sure you’re clear on what are the things, what are the core steps of this, that we’re definitely gonna make sure that we are following.
, a handful of examples that I know or must have are one is daily stand ups.
You have to have a daily stand up and Scrum, in my opinion.
If you don’t, days go by and time gets wasted, people get off track, accountability goes down.
Communication goes down.
So I’m a really big fan of making sure that you stick to the discipline of having a daily stand up every day.
Even if it’s only 10 or 15 minutes that’s gonna be really important.
making sure that you are, are, are, are keeping integrity of your sprint cycles.
So we, we typically will operate in two week development sprints and it’s really, common that people will stretch their sprints if they’re running behind.
or if they don’t have enough plan, they’ll cut a sprint off.
What I would encourage you to do is make sure that whatever your sprint schedule is to that sprint schedule.
If you’re not done with something on the last day of the sprint, you still close the sprint, right?
Be honest with yourself because it’s going to give you a lot of, of valuable information around.
What’s your true velocity and where are we getting stuck on things if something got planned and got put into the sprint, but didn’t get completed, we have to ask ourselves why and figure out how can we address that problem going forward?
Other process steps that are really important are making sure that you have a proper sprint planning, right?
There needs to be a step in there where the team is going over the sprint plan with the product owner and the product owner is in agreement that that’s what we wanna work on in that sprint, right?
Another one which is one of my favorites is sprint demos.
Like, like you can learn a whole lot about the status of a project by just doing demos and do them a lot, right?
So, typically we’ll do a sprint demo at the end of every two week sprint cycle.
If a pro, if a project is really having problems, I, I personally will do sprint or I’ll do demos more frequently.
Like if something is being worked on and we’re saying that we’ve got it completed or we made great progress.
Great.
Look, show it to me.
Let’s look at it right.
Spend time demoing it because you get a real handle on what the state things are and how are things moving forward.
And two, it, it creates a lot of accountability on the team.
People aren’t gonna give updates or be a little aggressive on saying that things are complete when they’re really not complete, right?
They’re kind of pulled together, but they’re not working properly.
There’s issues with it.
What do we gotta do to get done to be truly done?
Right.
And demos are a fantastic way to do this.
So make sure that’s part of your step.
And the last one I’ll mention here is just, you know, do you have a really good way of facilitating communication?
It’s very, very common for teams to work in more of a decentralized mode these days.
I know that we, we have a team that sort of spread all over the globe and a tool that’s been great for us is using Slack.
Slack is sort of a a group message tool that some of you may be familiar with.
One of the things I really like about it is that it, it’s a group chat related to a particular project or effort and everyone can see it even if you’re not a part of the conversation.
And so we even have our clients on the Project Slack channel.
So they can sort of see the chatter that’s going on.
And you know, the, the result of that is sometimes they see some silly questions get asked or somebody makes a mistake, but it’s right up there in open and that’s ok.
Like nobody really expects a project team to be perfect because this is hard.
And so the important part of this is that if there are questions that are getting asked and they are dumb questions, well, at least it’s getting addressed and it’s getting flushed out.
If people are giving instruction or input on something that’s the wrong direction, other people can have visibility that see that, correct it, or at least flag it.
They’re like, hey, we need to have a conversation about that.
So I just really encourage people to keep their conversations in the group channel for the project.
Try not to avoid little one on one side conversations because there’s a lot of efficiency that you can gain by having that visibility there.
So, and then, you know, the, the, the one last thing I’ll add on process here is that it’s really important to have somebody on the team that is responsible for making sure that you are following the process and that those steps or those core pieces of your process are actually happening, right?
When everybody gets busy, whenever they get under the gun stress levels go up because you’re on a deadline or you’re eating budget or you’re having issues in the project.
that’s not the time to be on a process that because we don’t have time for it.
Right.
It makes it even more important to follow the process at that point.
So, that’s our five steps that, that we think that if you’re having a project that’s having problems, you follow these five steps, you’re gonna be in way better shape.
If you have some thoughts on this or something that you think probably belongs on this list, I would love to get feedback from you.
So, let me see if we have some questions, I’ll give you guys an option on how to contact us with feedback here in just a minute.
But let me see here if we have any questions that came out on the chat, I didn’t see any come in from the webinar attendees.
Jordan generally, I know you guys, I think are on here as well.
I don’t know if there’s any questions that anybody submitted prior to the webinar that y’all wanted to go.
If you would throw those in there.
If not, I’ll kind of talk about feedback and how to keep up with us on some of the stuff and then if I see a question coming in, I’ll grab it.
Like I said, we love y’all’s input on the, the N O A answers webinars and this topic in particular, if you think there’s something that you should have included that I forgot.
Let me know, I’d love to hear the feedback or other future topics.
If there’s other topics that you’re coming across a lot, you think it would be valuable to hear us talk about some of that.
I’d love to, to hear that input from you as well.
Here’s a slide where you can, you can email us at info at N 08 dot com or I’m pretty active on linkedin, so feel free to drop me ad M on linkedin and let me know your thoughts, questions or if there’s anything that I can just do to help.
We, we love founders, we love folks that are trying to build awesome products, products that are gonna make an impact.
And so there’s any way we can sort of do to sort of help you on that journey.
We would love to, to help you any way that we can.
Thanks everybody that did join and we appreciate you spend a little bit of time with us today.
Hopefully, it was valuable and we’ll, we’ll, we’ll see you on our next session in a few weeks.
Thanks a bunch, everyone.
