Scoping Your Custom Software Project using Innovation Sessions
Presenter: Chris Daden
CEO and Chief Architect, DADEN LLC
Moderator: Karley Velasquez
Runtime: 31:47
Follow DADEN LLC
Over Budget or over Timeline on your Software Development project?
Our DADEN Software Virtual Event covers how our Innovation Sessions create effective Scopes of Work that will save you time and money in development. On average, clients receive 30-40% savings working with DADEN Software compared to our competitors.
Have questions? Ready to schedule your complimentary Innovation Session?
We are always here to help.
Webinar Transcript
(Karley)
Welcome
Welcome, everybody.
While we're waiting for others to join, I want to let all of you know that we will be spending the last 10 to 15 minutes conducting a live Q&A. For our viewers on LinkedIn, you can enter your questions in the event chat, and we will answer as many questions as possible.
Alright, thanks for joining everyone. Let's jump on it. Welcome to DADEN Software, Purpose Built Software Solutions for the Best Version of your Business. I'm Karley Velasquez and we welcome you to today's Virtual Event, where we will be taking you through the unique practices we use to scope software projects using innovation sessions.
With me today, we have Chris Daden, our CEO and Chief Architect presenting. Chris is an innovative leader who has championed over 150 mobile and web applications, yielding over $30 million in software deliverables. After completing hundreds of successful projects, using our 7-step development process, Chris knows the ins and outs of what needs to be done to ensure your project’s success. Let's get started. How are you doing today, Chris?
(Chris)
Presentation Roadmap
Hey Karley, thank you very much. Let's jump in. I'd like to go ahead and cover a quick roadmap for where we're heading today. We're going to spend the first 15 minutes covering about five different topics; the first being eight common reasons for inaccurate project scoping. The next is going to be defining innovation sessions and how it relates to project scoping. I'm going to give you some strategies for executing innovation sessions. Then, we're going to talk about how innovation sessions positively impact the scoping process, and I'm going to tell you all about the development cost savings that come from innovation sessions.
By the end of the presentation, you're probably going to start requiring innovation sessions for any of your software projects just like we do at DADEN Software. After we cover those topics, we'll jump into approximately a 15 minute live Q&A. We'd love to have your questions, so please, if you are able to drop them into the LinkedIn live chat, we'd love to see them, and we'll be sure to answer them at the end.
Eight common reasons for inaccurate project scoping
1 - Competitive markets and pressure from international workforces drive the urge to under-scope
First, let's cover the first bullet point for inaccurate scoping. One of the main drivers for inaccurate scoping is that competitive markets in software development and pressure from international workforces drive the urge to under scope. We're an agency in the software space, and we understand what it's like to be bidding against other agencies for proposals. This is a very common practice to feel like you want to under scope a project in the effort to meet a budget price or meet a time commitment, or otherwise, win a deal. Some tips for that is to just resist the urge. The competition will always exist, however, the competition that will under scope will lead to dissatisfied customers and clients. So we tell you, please resist the urge for this first concern and then make sure that you're quoting realistic task estimates, not just task estimates that the stakeholders want to hear. Make sure it's actually how much time something takes, not how much the stakeholders want them to take when you're bidding or scoping a project. We use a buffer time rule of approximately 1.5x because dev time does not equal calendar time. There are meetings, unexpected tasks, code refactoring, debugging test cases, and more to implement. Never just go for one for one. While you're bidding, yes, there's competition out there, but resist the urge to under scope. It's very important that you don't.
2 - Estimates are treated as fact instead of probability
Second, we have another leading cause, which is estimates being treated as fact instead of probability. We try to ask our engineers to avoid best case scenarios and we want to use time based ranges that are based on statistics. So that when we communicate something, for example, X feature has a 50% probability of being completed in the next 48 hours, and a 90% probability of being done in the next 72 hours, it's very important to use probability on those time ranges so the client knows that it's not a matter of fact. It will result in overall increase in client satisfaction when you communicate in a form of probability, over matter of fact. Make sure that in your scope, you have clear measurable milestones with statistics base time ranges, so that you can communicate effectively to your client base, and not speak in a form of matter of fact at the early stage of the project. As we know, in development, things change throughout the process, and there's obstacles that we encounter that will affect the probability of that execution.
3 - Teams rarely use historical data to accurately estimate future projects
The third item is that development teams rarely have the ability or have the dedication to use historical data to accurately estimate future projects. I would recommend that everybody use sample past projects as an indication of future performance. So, if you ran over on the last four or five projects, you can take a sample of the reasons why a sample of the estimated time frame versus the actual task magnitude, and you'll be able to use that to predict future timelines. This is another common inaccurate scoping concern. Also, we have the real time velocity from a project. If you measure your current project performance and you recalculate milestones frequently based on real time velocity in a project, you're going to do a much better job keeping on track, keeping expectations managed, and keeping the overall project successful. Those are just a couple of tips to counter this if you’ve experienced this in your scoping process.
4 - High level tasks are created but subtasks are not
Fourth, we have that high level tasks are created but subtasks are not. We'd ask you to avoid saying that this task will be completed in approximately one to two weeks, or this grouping of functionality will take two weeks to complete. We want you and we ask our team to break up tasks in one or two day increments at most. We always say, like everybody, the devils in the details. Subtasks are key. So break out those big, larger development items into smaller sub tasks. Make sure that you're really looking at those details to be able to early and often identify the risks in the project accurately, and also identify responsible parties for each task and subtasks. When you assign responsible parties to each of those, whether they're developers or project managers, it really does help shape the level of responsibility the team feels towards those tasks and it will result in a higher success average as an outcome for your project. Also, what's very important in software development is communicating task dependencies. Make sure that you're saying this piece of server side development needs to be completed before this piece of front end development, or it's a blocker for that team. If you don't identify those dependencies earlier on in the development cycle, you're going to end up with some timeline problems and some scoping issues. So while you're scoping, it's very important to go through and flesh these tasks out and identify those dependencies and more.
5 - Project size is too large without necessary checkpoints or micro-deployments
I would ask that if you do have to do such a large project or an enterprise system, definitely break it out into phases. You can have subsystems modules, you can say Phase One, we're going to do the foundation and the system. Phase Two, we're going to do billing. Phase Three, we're going to do user interface and client logins. Please break it out into phases because any project that is too large is going to have a higher percentage of scoping inaccuracy and you won't realize it until you're deep in development, and you've likely already committed pricing to your client or to your stakeholders. In that matter, we always try to deploy more to production. So like I said, if you go under this waterfall approach, and you're working on something for a very long time, you will much less likely push to production. When you push to production, it forces you through making sure the code is stable, making sure the environment is good, making sure you have good deployment practices, and making sure you have good code review. What that's going to do is, it's going to force you to run a tighter ship and deploy to production more. It will be better for the overall project in all aspects, so push frequently.
6 - Failure to de-risk the project early
All right, moving on. Number six, as developers, project managers, stakeholders, executives, or whatever you are, it's very important in the scoping stage to de-risk the project early so you have to identify areas of difficulty. Ask your developers to write sample code or small prototypes. An example would be something like hardware integration-- maybe you're using Beacon technology, or Bluetooth technology or anything like that. Ask your lead developers to write some sample code, build some prototypes, go to some developer meetup groups, make sure you ask around, and make sure you can get ahead of de-risking those components of the project very early. It's very important to then after you've written those sample code, or small prototypes, tackle those difficult components early in the project, because it'll then remove risk from the overall timeline. If you do all the easy stuff first and you take weeks and weeks at the beginning of the timeline to do the easy things, at the end is where you'll end up getting stuck with all of these difficult components that you save for last. That is going to be a huge risk to your project timeline. And always, when you can, try to assign and allocate dedicated resources to these higher risk areas, so that it's easier for you to keep an eye on, and always communicate the risks and steps to de-risk to the client early on. We'll talk about that more when we discuss the innovation session structure and strategy in just a minute.
7 - Client/Project stakeholder is not fully read into the project complexities and expectations are not set
Next, we have an all too common problem that the client or project stakeholder is not fully read into the project complexities and expectations are not set. This is by far the number one reason that clients get unhappy with development. It's very critical that you list specific objectives, that you break out specific screens, and specific functionalities. You need to rank each feature by difficulty estimate, the time to build and avoid these widespread statements of summary based estimates-- like this module will take two to three weeks, this area of the apple take three weeks, referring to a registration flow, or anything like that in a wide span scenario is what we'd like to avoid, because those are summary based estimates. The devil is in the details with those. While you're doing this, we'll talk about this in the innovation session part of the presentation, but you need to have your client and project stakeholder interacting with this, because they need to feel like they're part of the team, and they need to feel joint responsibility. They need to feel accountable to these difficult scenarios, well in advance of them becoming difficult or problematic, so that you can collaborate effectively between your client and agency relationship. Or if you're a product based company, you can collaborate with your executives or your stakeholders internally to make sure that everyone's on the same page.
8 - Project lacks specific objectives or goals
And finally, the most important reason for inaccurate scoping occuring is that projects lack specific objectives or goals. We have clients approach us a lot and say, I want to build an app that does XYZ, but they really don't understand fundamentally why they are going to create the app or what the objective or goal is. In enterprise software, it's very critical that you have narrowly tailored business objectives and write those project goals in a Google doc or specifically, so that you can really hone in on those. When the project gets uncertain, you can go back to those project goals and ask yourself, does this requirement line up with the project goals, and if it doesn't, you need to be prepared to cut those additional requirements. As a product manager or a project manager, you want to defend those goals as much as you can to make sure that the original scope is protected and intact so that you avoid feature creep and avoid an expansion of the scope. Even if the clients are willing to pay, we often like to control the scope and add those as future exhibits to the contract later on, so that we don't really blow up our originally committed time frame. A lot of times clients or stakeholders aren't really clear that adding XYZ features is going to extend the timeline by two weeks, three weeks, and inevitably miss certain milestones that the business needs to achieve. So another method we like to have is considering anti goals. So, just as important as having goals is the concept of anti goals. Make sure that you use anti goals meaning, things that you definitely don't want to achieve as another metric to evaluate whether or not requirements can be cut, in order to keep a timeline or a project on track, budget, timeline, etc.
Scoping you project with Innovation Sessions
What is an Innovation Session
So now that we've talked about these eight common things that cause inaccurate scoping, I want to get to the meat of the presentation, which is how we use innovation sessions at DADEN Software to more effectively scope. I invite you guys to see what we do and employ this in your business itself, or in your business units in your departments. If you're from other industries in your team, this works not just in software industries, but in any other industry as well. So if you're from, I know a lot of the attendees today are from different industries, think about this innovation session, in light of your specific practice.
Here's our definition of an innovation session. We call a custom software innovation session, an interactive and collaborative session or sessions between project stakeholders and members of the project management, development and architecture team that take place in order to accurately scope the project. These sessions include a focus on software context, flow, goals, objectives, and specific screen listings and functionality specs. We bring everybody together earlier on in the project. In fact, we bring it on presale to make sure that everyone's on the same page before we write a contract for a project and we bring everybody together collaboratively. I'll show you pictures of some of the sessions we run, we have a lot of fun and we really understand the goals of the project. We follow a very systematic agenda to make sure that we fully grasp the important components of the project. That is our definition of an innovation session.
What an innovation session does in so much as a process flow, is you may have one or three or five innovation sessions, and it paves the way towards wireframing and then inevitably, doing a design prototype before you enter into development. But today, the part of the funnel we're focusing on is the innovation sessions preparing you and the client for the scope towards the wireframing session to make your product, and your project much more likely to succeed. Just a comment, our philosophy is that the innovation session should be free. We like to provide our mental power as a team to prospective clients, into active clients to really innovate and think about ways we can achieve things. And we really provide that as a platform for our clients to get the information they need to make the best business decisions for their software. And we conduct these pre-sale to reduce project risk and maximize client satisfaction. So if we are in an innovation session for a prospective client, and we realize we can't achieve their project, or there's technical limitations, we've saved everybody a lot of time by not going into contract spending a bunch of money and development just to realize the project isn't successful. We really, really do recommend doing all of this presale if you're an agency, or if you're a product based company or an entrepreneur, do this pre-creation of the product. You can plan it all out and put that intellectual power into the front end of the process when it's much more cost effective than doing it in the middle of development and wasting or burning a bunch of cash.
We use whiteboards, we do it in person, we typically do it over an office lunch. We have the whole team there; architects, PMs, clients, developers, whatever we need to bring all of our minds together.
Tools We Recommend
We recommend engaging your team by hosting something at your office using whiteboards. If you don't have whiteboards, here are some tools we recommend. We use paper, we tape paper to the walls, we use those big post-it sticky notes that go on walls, we have markers, or even virtually, you can use Zoom whiteboards if you're all together in a remote, collaborative environment. We use G-Suite to do real time note taking and a central storage for ideas. We have mockups.com as a wireframing tool for black and white wireframes. Once we exit the initial innovation session, we use a PM system, maybe Teamwork, Asana to do anything like that, you can use your project management system. It's important to have the Invision app, maybe you're going to then take those black and white wireframes and create visual mockups for design. And then of course, Keynote, PowerPoint slides, post innovation sessions to really summarize and bring everything together for your client.
How to Execute Innovation Sessions
Here's a sample agenda that we use for innovation sessions, so feel free to take this and use it for your in house innovation session. First, we talk with the client about project priorities and objectives and we just list everything out. It's kind of like an information dump. In these innovation sessions, we want to capture all of the ideas. We want to cast a really wide net and it's very important to get all of the priorities and objectives, get the timeframe and budget from the client, talk about technology. Is this a native iOS app, a native Android app? Is it a web application? What type of database will we use? That's why you have to have the developers in there to really get that going in the architect. You can balance that with all of the considerations of all the different disciplines within the team, and you want to list the major features of your application. You want to list screens within that application as well, describe them, write the purpose of the screen, write a description of the screen, and then you're going to make sure that the flow of the screens are generally dictated. So if you write them in order, or draw arrows between them, those are all effective ways to do that. Once you have all of this information, and this might take an hour, it might take two hours, it might take 30 minutes, depending on how complex your idea is, but once you have all this information, you've really got the DNA of a project. That's why this innovation session is so critical to scoping and offsetting the risk of a project.
Post-Innovations Session(s)
When we exit an innovation session, we create a summary document, which is typically in Google Slides, or PowerPoint, and it has pictures of the actual innovation session drawings like this. It has basic black and white wireframe mockups. Then from there, we attach all of the raw photos of the actual innovation session and then we're able to bid or quote a project. You can imagine using these thorough practices, and having these innovation sessions allows us to effectively and accurately bid a project without the risk of over bidding, under bidding, over committing timeline, or under committing timeline. Most agencies will just throw a price at a project, and most stakeholders will want their developers to throw estimates or times at a project which often end up in accuracies.
Post Impacts on Scoping
So just to recap, here are some of the positive impacts on scoping when you use innovation sessions. We squash those first eight concerns that we've had with scoping when we follow this disciplined process, but we also have a clear understanding of the project requirements. It's a very easy transition from idea to concrete wireframes. Sometimes of our clients struggle to communicate their ideas to us and innovation sessions really, really solve and help for that. We have expectations set real-time, because while we're planning and we're talking about features, the developer or architect in the room can rank and prioritize what is more complicated than what is within our budget. This is the best way to approach it versus this way, and you can really eliminate and ideate a lot of the extra problems that could occur later on in the development cycle. You avoid scope creep by being specific, you're collaborative with the client, you can say look, we didn't talk about that in the original stage, let's stick to the plan, stay on track. You can advise and provide expertise in a cooperative fashion, you're actually working side by side with your client, or side by side with your department, or your team, or your stakeholders. So while you're planning on the whiteboard, it's a neutral environment for you as an expert to be able to provide expertise in a cooperative fashion to your team instead of coming across like you are offensive or not listening to their ideas.
So don't be worried, efficient innovation sessions can take 30 to 60 minutes, but we do them pre-sale, so we can do them pretty quickly. It really does give you an opportunity to evaluate the quality of a partnership. If you're doing it as an agency, it's a great way to really kind of interview your clients and have your clients interview you. But also, you can use it internally within your team to see which ways of collaboration are more effective to get the job done internally in your product or entrepreneurial company.
Cost Savings
This is the most important slide of the whole thing. We do innovation sessions because on average 66% of software projects run over cost. 46% of projects are over timeline and 44% of projects have functionality shortfall. Our innovation sessions have led us to lead hundreds of successful projects for more than $30 million in deliverables, so we know it works. We know it offsets these average software industry statistics, so it's very important that you guys leverage these innovation sessions in order to overcome these concerns and deliver on time and on budget with all of the features originally promised and scoped to your client. So for us, we estimate 30 to 60% development savings using our seven-step development process. The first step of our seven-step development process is a heavy focus on these innovation sessions. They are absolutely critical to our business. We hope that with the presentation today, you can employ some of these best practices, call them whatever you want, call them innovation sessions, call them exploratory sessions, no matter what it is, employ them in your business to provide this continuity, effectiveness, and enhanced process to your software project.
With that, I say thank you so much for listening. I know we had a great amount of attendees today, we're super excited that you guys joined us. I would just ask that if you would like us to run an innovation session for your custom software project, I would love to if it's an idea in one of your departments or your teams, or if your startup and you want to do this and you're thinking about building some software, I would be happy to personally run an innovation session with you guys. You can email me here, my email is at the bottom, chris@dadenllc.com. You can also contact us through our website. But I'd love to offer that to you guys as a compliment and walk you through a session for your team. And with that, I'll pass it over to Karley, so we can wrap up and head into the Q&A
Live Q&A
(Karley)
That was some great information, Chris. Hopefully all of our attendees learned a lot from that. We do have some questions here. I think we only have time for about one or two, and then we'll answer the rest of your questions that have come in through the LinkedIn chat event session and we'll go ahead and answer a few more later on. But let’s go ahead and answer about two right now.
So Chris, looks like one of the first questions that came in is, which types of team members should I include in innovation sessions to make sure it is a form of effective planning?
(Chris)
Great question. I think it's critical that you have somebody from each discipline or function of the team in the room, because it really is a collaborative session where you're trying to get everybody to weigh in from different perspectives. I would encourage somebody from sales, a developer, an architect, an executive, like COO, CEO, hopefully, if they're engaged, and they can set the vision for the product. Include as many disciplines as you can, because everyone has a different perspective and the innovation session is all about capturing general thoughts and ideas. And it's just important to get everyone at the table at the beginning so that things don't come up later on. If you have a support lead, or anything like that, get them in the room too. The answer is, as many people as you can from different disciplines within your organization so that you can get all of the perspectives.
(Karley)
Okay, so our second question here is, how do you recommend I compete with improperly scoped and dishonest competitor offers?
(Chris)
So this a tough one. I think, like I said at the beginning of the presentation, you're always going to be competing against people that will under-scope or under budget or undercut, especially with pressure from international workforces. I would just say that you ultimately leverage your relationship with the client. That's another reason why these innovation sessions are so key, is you're building, especially if you're doing the pre-sale like we do, you're building a bond with your clients and they trust you, and you trust them. You're really learning how to collaborate together, that is a value that other competitive developers that are under scoping or under bidding will not be capable of providing, and that's a key point to highlight. Just lean on that relationship, lean on your tools, lean on your process. That's going to be the most effective way to remain competitive even if other people are under scoping or under bidding, and let your clients know about the risks of what under scoping or under bidding will do. We've had clients that don't listen to us during the proposal process, and they end up coming back, three to six months later asking us to take over the project or rebuild it from scratch, or whatever it is. So just be honest, transparent, and lean on that with your clients.
Thank You
(Karley)
Great. Well, I think that wraps up our presentation today. So thank you, everyone, for joining us, and we hope you found all of this information useful. If you do need additional advice, we would love to help you. Please reach out, we can set up a one on one meeting with you. Also, keep an eye out for next month's virtual event. And if you have the chance, follow us at DADEN LLC on LinkedIn. You can see on your screen that we have a QR code, so you can scan that easily and you can start receiving notifications for our upcoming events and more software development strategies, similar to what was presented today. We did have some more great questions that we just couldn't get to, but we'll be answering those in the event chat on LinkedIn at a later time. Thank you, everyone. I hope you have a great rest of your week and we'll see you soon. Bye.