Webinar: Project Planning: Architecture & Discovery

But thanks for joining us. Today's topic is architecture and discovery, the foundation of every project that we do here at the NP Group, a super important phase. You can't go through a development design project without doing discovery first. Again, thanks for joining and let me just take you through what today's agenda is going to be.
Today we're going to be taking a look first off at some introductions, who I am, talk about the topic. I'm going to talk a little bit about how you procure digital services. We're going to dig from there into software development methodology, talk a little bit about the development cycle, talk about why discovery is important and what the process looks like, and then do a little Q&A.
A little bit of introductions really quick. Let me just fix this. I am Pete Czech. I'm the CEO over here at the NP Group. We founded the company back in 2001, so we've been doing this for a little while. My personal background is custom web development, little bit of UI/UX, project management, and that's my email if you ever need to get in touch with me, [email protected]. Czech like the country.
A little bit about what we do. We're the experts in development of safe, secure custom content management systems. We focus on custom web development and custom design to create websites and applications for customers with complex requirements. Nothing really off-the-shelf. We do work with certain off-the-shelf technologies, but we try to extend them with custom functionality to help our clients get a little bit more out of the software. These are just a few of our customers. Like I said, we've been in business since 2001. Some you might have seen and heard of, some you may not have. The key thought with each one is the custom work that we've done for them. 
Why are you here? For a couple of reasons. First off, perhaps you're undergoing a design and development project or you will be. Perhaps you've had a bad experience in the past with a development project. Obviously that's something which happens more often than any of us would want to admit. You might also be curious about website discovery and planning is all about. All these topics we're going to dig into. For the purposes of this webinar, I'm probably going to have about 20 minutes worth of slides and things to tell you. After that, we're going to do some Q&A, so if you have questions, feel free to submit them on the GoTo Webinar panel.
First I want to talk about how you procure services for people when you're going to hire people like me. The procurement system, it's massively broken. It's using old world methods for a new world type of service. In this case, nightmare projects begin most typically in one of three ways. The first way is RFPs, and I'm going to dig into all of these in a little bit. The second way is price shopping only, not pricing on ingenuity or thought leadership or anything like that, but just shopping based on price. Then obviously after that, quoting based on home-built specifications. Each one of these typically leads to a nightmare scenario. 
First, I want you to remember. My goal as an agency and any agency is to do the best job possible building out your project. Our reputation matters. Most of us base our business on referrals. Business development is a challenge and it's a very competitive space, so our goal is always to keep our customers as happy as humanly possible. We are there to exceed expectations. I'm laying that out there because I'm going to complain a little bit about procurement and I just want to remind you about why we're here.
With that, the problem with RFPs. RFPs are really an outdated methodology. It's something that we actually see a lot of it with East Coast clients, we don't see a lot with West Coast. I don't know if there's some sort of demographic breakdown there, but the old world thinking of acquiring services as you put out this document laden with requirements and then you just get prices back, but there's a ton of problems with that when it comes to digital services.
The first thing is it doesn't focus on digging into problem-solving pretty much at all. It focuses on listing requirements, and they don't even really detail why those requirements are there. As an agency, it's very frustrating because the RFP process means there's almost no communication. We can't get in touch. Typically there are rules that would even restrict us having any communication, which is even more frustrating. 
It's usually sent blindly, so the people that are issuing the RFP will send it to a ton of different agencies and they're not even sure what the core competency of the agency is because they've never spoken. I've literally gotten RFP submissions through a contact form. Really the reward here is to complete the list at a low price as opposed to bringing original solutions. One of the things we do when we see an RFP is immediately try to get in touch with somebody there, and if we can't, we actually don't participate. RFPs are definitely broken, and this is all going to come back to discovery in a minute, I assure you. 
The other problem is just flat-out price shopping. It's very hard to acquire digital services for production or design just based on price alone. Typically, these are people that want to have a price after a very quick conversation or sending over a document. The issue with this if you are a price shopper, and I identify with this, by the way, because anything I do in my house, I'm a price shopper. I want to know what something's going to cost, I want to know a range before a conversation. The problem is with digital services you have no idea what you're getting. You can't compare vendors on this alone because there's different types of vendors, some who might really need the work, and they're going to go out and make all sorts of promises and this and that based on the price they think you want to hear. There's going to be others on the other side of that argument. 
You've spent no quality time with the vendor, so this leads to a disaster quite often because you're going to get a quote, but you have no idea who these people are. If you commit, you're going to be making a big commitment based on very little information, so trust me, this is actually the worst-case scenario when you're just shopping for the lowest cost vendor. It never works out well and a lot of those people end up coming back to us one way or another.
Another thing I see that leads to disaster is home-built specifications. The biggest problem, typically they don't specify anything. People come to us and we try to encourage them to go through the discovery process, and they say, "Oh, well, we have a specification." I look at it, and typically it's full of holes. You're not developing software regularly so you're not going to know what we don't know. The biggest problem is there's a difference between requirements and specification. I feel like a lot of people that come through with these documents, it's a requirements document that might be maybe a couple of pages, but it's not really a specification.
Discovery is what we're trying to bring to the table to solve all these problems. We're trying to have a complete definition of what a project is before we begin with it. If you look at it here, and a lot of the discovery we're going to talk about today is going to be aimed towards design and development from a digital perspective, but in my definition here, the purpose of it is to interpret your business goals and translate those into technology requirements. 
The benefits really quickly is that first off, you get to date before you marry. I love that line, I think it's very important. A lot of the success between a vendor and a client is going to be a personality issue as much as capability, so if you just go through one phone call, get some quotes, choose the lowest price, or go through a blind RFP process, you have no idea who the personalities are that you're going to deal with. Discovery lets you have an initial project and undergo that and get to know who these people are, because typically when we do discovery, we'll bring in the project manager, the art director, the people who actually work on these things so you actually get to know the parties involved.
The other thing about discovery is you're going to fill in the gaps. There's no way you can consider every possible scenario and requirement of your project. We're going to be able to fill those gaps in for you. Then finally, if you don't go through that, how are you supposed to get bids and know what it is you're paying and what it is you're receiving if you don't know what the spec is? Discovery is the cure for all of these various issues in the procurement process.
Really quickly, where discovery works the best. It works really great on website design obviously, web app development, it's super important there where you have to have a lot of moving parts and you're coding now is some kind of custom framework. Digital marketing services. It's important there as well. Even just down to UI/UX design and front-end development, there's a lot that can be accomplished through a discovery process there as well.
Digging into each one, each one should have a different purpose. If you're doing a discovery for a web design project, the focus has to be purpose-driven design. We would dig in a little bit deeper to who are your customers? What are their goals and objectives? In the former, determining who are the buyer personas? Who are those people coming in? What's their demographic information? What's their level of knowledge in terms of utilizing the web? Things like that are going to be important. What are their goals? Are they coming to buy something? And this leads into conversion points. Are they going to become ... Is it a lead gen site? Is it something where you're trying to sell a subscription or products?
Then finally, one of the things we got to focus on is what's statistical success so that we know in six months when the project's done that we've met these goals? What's going to be the ongoing metrics that we're going to be concerned about? These are just a small sample of what you would look at, but some of the important topics in terms of web design discovery.
The next one where it's super important to do discovery, web application development. This is the majority of the discoveries that we do. Mostly it's around complex custom development. The idea here is to build that specification. I was thinking about this as I was walking into the office just before starting, thinking that the service that I provide is so unusual when you think about contractor type of relationships. If you're building a house or working on a kitchen or a roof, you have some sort of oversight, you have permits from the town, and you have all these certifications that people go through, and really in our business, things are not designed as well. You could literally come in and build something that's as big a project as building a house and not have a blueprint for it. It's crazy and it actually happens all the time, so our purpose, again, is to build that well-rounded, well-developed specification.
The way we'll do that is by asking questions such as what's your minimum viable product? What is the smallest project we can do that can show initial success? What are technology requirements? Different organizations have different tech requirements. Sometimes there's none and we might use that time to just educate and talk about the possibilities. Who are the system actors, the people that are going to use this system? What roles are they going to play? These are things that we'll dig into.
Another one. What's the business logic? What's the purpose of what we're doing? What are some of the system functions that are going to be performed? All these things have to be approached and discussed, and the end goal on a discovery like this is a wide-ranging document that's going to be many pages long, full of models and flowcharts and really dig into each one of these things specifically.
Another place where this works, digital marketing. Very important for digital marketing to have a sense of what an initial marketing strategy is. We do some digital marketing services. We have another brand agency here that does it as well. Typically, we spend the first month of the arrangement just doing development of the discovery and the strategy. Again, kind of like design, who are the buyer personas? In the past, what's worked? What hasn't worked? What have you tried? What have been the findings? What are your conversion points? Again, like web design, are you selling something? Is it a signup? Is it lead generation? Community? Whatnot? What's an ongoing budget? Marketing's something that you can get places faster if budget is higher rather than smaller. It's just another thing to consider. 
Then we'll talk about mediums. Is it content creation? Is it organic? Is it search engine optimization? Is it paid campaigns? All those things should be thought out and laid into a plan, an initial strategy based on the discovery session or series of sessions in the case of marketing. 
A final place where a discovery makes a lot of sense is UI/UX design. We see that now front-end design and development is actually separating a little bit from back-end, and in some cases it requires its own layer of discovery services. In this case, again, we might look at existing statistics, study user behavior if it's a redesign, we'll think about what devices are people using. Again, goals and objectives and things such as that. There's a lot more on the technology side these days in terms of front-end that we would have to discuss. 
A discovery for UI/UX alone is definitely worthwhile. If you have an existing back-end system and you're putting a new skin on it, it's worth spending time with an agency to build out what that project's going to look like. Again, there's just too many unknowns to be able to bid those projects without spending a little quality time together.
With all those examples said, our focus today is really to talk about app development, web app development, and with that I want to talk a little bit about software development methodology. This might be ... If you have experience in software development, you're going to know what these terms are. If not, there's a ton in our blog about it and on our site and other areas as well.
The two major methodologies right now for software development is the Agile versus Waterfall method, where basically, the graphics here and the naming conventions tell you exactly what they do. On the Agile side, this is much more of an input-based type of development methodology wherein as a development team, we work with the client on a regular basis to understand what the next sets of goals and objectives are going to be. 
Agile is exactly what the word says, it's an agile approach, it allows for uncertainty, and it's kind of nonlinear, and then you can jump from idea to idea and concept to concept. Where this has some cons is that there's no assured deliverables. You set goals over a timeframe that you want to achieve. The other negative is it requires larger commitment from the client.
We work Agile at the NP Group in sprints. We might do a two-week sprint, which with one developer would be 80 hours of development and you might be working the project manager as well. The big difference here is at the beginning of the sprint we're going to say, "Okay, these are the goals for the end of the sprint and let's meet every other day until the sprint's finished." With a Waterfall project it's going to be designed a little bit differently. You're going to meet a little bit less.
The pros here I feel outweigh the cons in that you have that flexibility, you see daily improvement and progress, so the Agile methodology is very popular. The other one today is Waterfall, which is a much more sequential approach wherein we base a project on deliverables or output. Again, Agile is input based on the things that we determine we're going to do together. Output is based on these are the deliverables that we've already agreed to. 
The pro to it, it's easier to plan what those deliverables are going to be and sort of schedule it, but I will say on the cons, almost always there's going to be a schedule issue, and this is something I'm willing to admit. It happens to almost every development shop. If there's one little delay in the beginning of a project, it can obviously set the entire project off because this is running in a sequential order.
Some of the other cons is it is kind of inflexible and it is rigid, so if you've built out a spec and you've agreed to that price and you've agreed to what it is the deliverables are going to be, as you get through the project, you might realize, "Hey, I think I want to change this or I think I want to change that." Well, that's where your typical this isn't a four-letter word, it's two words, but work order, that might come in, or maybe you're talking about swapping functionality. There's a little bit more account management that has to happen on a Waterfall project. Again, it runs in a linear fashion, so the process is typically starts with, again, the discovery we're talking about, design, front-end development, back-end development, and then deployment from there.
Now, with these two being said, the most common arrangement is Waterfall. I'm a little prone to be a fan of Agile. I kind of like the workflow there. In terms of Waterfall, the buyers, customers, they prefer deliverables and milestones. It's easier to sell, it's easier for them to manage, it's easier to talk to the finance guys to be able to get the approvals. It's kind of a negative and I'm kind of sad, the agencies, we don't sell Agile well. There hasn't really been a great way to come in and sell it because again, there's not those set in stone deliverables and milestones. At the end of the day I think you net out a little better with an Agile approach, but again, it's a harder sell. 
I have come to fully recognize that Waterfall is the way that people want to go, so we have honed a process to be able to make those projects as successful as possible, and that's where discovery really, really matters. This is what a process would normally look like in terms of a Waterfall project. It starts obviously what we're talking about today, step number one, architecture and discovery, but then it goes into design, front-end development, back-end integration, testing, quality assurance, release, and then ongoing improvement, where improvement can be something that's more from an Agile perspective. Again, this is the Waterfall approach, but if we can get through the discovery process with a well-formulated spec, we can mitigate those risks that we spoke about and make everybody happy in terms of getting these projects underway, and that is really the goal of what we're talking about today. 
The discovery process, this is how we perform it. Other agencies might do it a little bit differently, but typically these are the phases and the steps. It always begins with an initial discussion, which is just a quick phone call for me to talk about top level, what is your project? What are you looking to do? And onto discovery meetings. Actually, I'll skip through this fast because I have some slides for each one. We have our discovery meeting sessions where we get together and spend some really quality time. Every project's different. Sometimes it's two hours, sometimes it's two weeks. It really depends. We deliver the findings, we work on the revision of the findings, and then it comes into a proposal.
Really quick in going through these ... I'm always time-conscious by the way, so I'm going to talk fast, but again, if you have questions, feel free to submit them on the GoTo webinar. Initial discussion, this is the time for you to get to know me, where we discuss, "Hey, what is, at a top level, the concept? How well-developed is it conceptually?" We would have a top level conversation about how the discovery process might be specific, change specifically for you. 
What's success going to look like when the project's done? That's something I want to know at the beginning. It's very helpful first off for me to determine if it even is a fit. We're not the perfect fit for every project that's out there and we like to weed that out and figure it out before we waste each other's time. Also, we like to get a sense of what parties are going to be involved in the discovery process. Who's going to be a part of that meeting? That'll help us hone in an agenda specifically for your purposes. 
The discovery meetings themselves, this is really the centerpiece of the entire process. This is getting together with those people in in-depth sessions, starting with group sessions, moving into individual scenarios where we interview every single person that's a part of the team. We don't want to over-complicate it, we don't want to meet with more people than we need to meet with, but we definitely want to meet with the stakeholders, the people who work with the stakeholders. Sometimes that could be two or three people for a project. Sometimes we've done it where we've met 30 or 40 people across different locations. It really depends. Again, this will vary based on the project or your company's scenario.
The one thing we do say is let's keep each of those sessions on an agenda. They have to be agenda-driven. It can't ... I'm not as big on a round table where everyone sits around and just throws items out there. We don't find those to be as productive, so we bring in people from our company that manage these sessions and keep everybody on-topic so we can get the most valuable information out of each one of these sessions.
A sample agenda, the best process, again, will include an agenda personalized for your project, but the stock agenda's typically going to dig into these items. If you are ever going to go through a discovery process, take note of these now because these are items of discussion that are going to be covered exhaustively throughout the day and throughout the process. First, business overview, what it is you guys are doing, what differentiates you guys from your competitors? Challenges, marketplace, things like that we're going to want to know about because we're going to want to be able to ... Again, what are we doing? We're giving you a technological interpretation of your business requirements, so we need to understand your business to be able to do that properly.
We're going to want to know who the audience is and the personas. Regardless of if it's a marketing or a development project, we're going to need to know a little bit more about the people that come in. We're very interested in competition, mostly because it gives us insight into you guys, into the customer. We like to see who you're emulating and looking at and why. Is there a reason? Is there a fearful reason? Is there you're completely enamored with your competitors? We want to know why and dig in a little bit to that.
If you're building a startup or if you're an established company, we are going to be asking questions about marketing and how you plan to be getting people through the door of these projects. Helps us in terms of when we're going to build it, front-end considerations. It all sort of ties into what your marketing initiatives are. From a development considerations perspective, that might be talking about technology and do you have any preferred platforms or things such as that? We'll definitely want to cover that. Great time to bring in an in-house CTO or technology IT director. 
Then digging into specifically what it is we're building. Again, in my example here we're talking more from a development perspective. Who are the users of the system and the actors? What are they going to be doing? What are their roles? What are the tasks that they're going to be performing? That's really getting down into the nitty-gritty of a technical specification. 
We're going to talk about design, so I might bring in an art director, another designer to get a sense of your personal design sensibility. Obviously if we're doing an informational site, a marketing website, B2B site, we're going to spend a lot of time on this in particular trying to get a sense of do you have brand, a style guide? Do you have brand guidelines? If you don't, do you need help developing those? If you do have it, well, what's the aging on it? How long has it been there? What are some of the uses of it in the past? Does it need revision? How do we tie that all together to make a web user interface and user experience? These are all things that we're going to want to discuss.
Also content development. This is something that on the web design side we're going to spend a lot of time doing that, but also on development side. You'd be surprised at how often we have to build out content for these individual projects, so we'll talk about that. And then finally, monetization. Super important across almost every project. For informational sites, we want to know what are the products that you're selling? What are the options for it? How do you want to best present it? Obviously. 
When you're talking about subscription-based sites, SaaS platforms, those types of online software, we need to have a really good sense of what your monetization scheme is going to be because we're going to have to build software for that. This is especially important with SaaS applications, where you have so many different levels of pricing that you can do, coupon codes, discount plans. What are the features between each plan? This is something that has to be dug into at a very detailed level throughout the discovery session. 
With all that, how do you best prepare for your discovery? Have some internal meetings before. Try to identify two or three key stakeholders if you're a large group so that we know who we're going to be communicating with throughout the process, and be clear on the goals and objectives internally. Don't come in and argue with each other in front of us. That's not going to be the most productive way to go because then we're going to have to referee that on top of everything else. It's best for you when you have the agency in front of you to be aligned in terms of what it is you're trying to achieve.
That carries through to your business logic and requirements. You could be a little bit looser on this, but try to have some level of agreement. If you're building out a startup piece of software, don't be completely disagreed on how the thing's going to work. That's not going to lead to a productive day, but if you know at a top level what it is you're doing and maybe you have a question about X feature versus Y feature and what the best workflow is, that's perfect. That's what we're there for. We definitely want you to have some clarity on this, but it doesn't have to be perfect.
From that, it's great to bring in examples of competition that you're inspired by so that we can have a look at it. If you have something completely unique, then we're going to ask for some other ways to gauge and sense what your style direction is, but it is important to bring that. It's kind of rare that we see somebody without any competitive examples that they bring, but it has happened.
Then think strategically ahead of time about where some of your roadblocks might be. It's kind of hard to do when you've looked at something for a long time and you've been completely focused on it. Sometimes it's hard to see what your roadblocks or obstructions are. We're going to be able to spot them pretty quickly actually when you go through the process, but we want you to have a sense of what you think they might be. I think that that's really important to bring to the table because what seems to be a roadblock to you might be something where we come in and say, "Hey, this isn't really much of an issue at all." On the other hand, we might discover something that could be a killer throughout the process or during the process as well, so we like to have you come to the table with an idea of what those roadblocks might be.
Assemble the right-sized team of participants. Again, we've done discoveries with large groups, we've done it with very small groups. I think the smallest one was with one person and the largest was with like 40 people. The right-sized team for you is really dependent on your organization. There's no right answer. What we can do during the introductory call, like I said, we identify who those people are, we can give you some tips and some ideas about how to identify who should or shouldn't be part of the process.
After this is all done, after the meeting is completed, that's when we get into the delivery of findings. The way that we like to break these down is obviously we do some overview, some executive summaries. If you're currently already going concern, then we might talk about what your current situation analysis is, and then we'll dig into the requirements. Remember, most people that bring us what they call a spec. They just bring us requirements, so that will be part of your findings document, it'll just be a more built-out version of it. We'll talk about what the requirements are.
Then this is where the real value of discovery comes in, the recommended implementation. We've done I think four or five discoveries in the first half of this year already. Some of these documents gone up to 40, 50 pages. A lot of that is going to be recommended implementation, how we're going to build it, what's the actual technology background going to be? What are some of the features? These get really complex with development projects, a little less so with design, but it's definitely ... Like I said, you're going to extract the most value out of this recommended implementation.
The next part of it would be your architecture in your specification, and those are going to be more technically built-out. It's actually more so to guide us if you go ahead with the development of the project, and also, and I say this to everybody in complete honesty, you could always take a discovery from one agency and chop it with others if you think that you want to do that. This area is where we're going to break into every little bullet point of how this project is going to work. In some of the examples that I did earlier this year, we had 20 pages alone maybe talking about architecture and specification. That is, again, that's the value that you extract from the process, the recommended implementation, the architecture of the spec.
After that, what we like to do, obviously you've come to us for a reason. Hopefully it's because you want to actually go through with the project. We like to give you options, a high, medium, low, a small, medium, large so that you determine what next step is right for you. After we deliver that, we want you to go through a round of revision. It's very important that you do this, and you really have to take your time to do it because this is going to be an in-depth document. We're not asking you to learn to be a technology guru, but we are asking you to put in the time to review the document and make sure that we have everything that's essential for the MVP. 
This is your opportunity to correct any items that we might have lost in translation. It happens, and that's, I think, a healthy part of the process. Things are actually lost or maybe misconstrued or misunderstood or whatever. This is an opportunity to fix that. Again, the findings document with the spec, that will be the foundation for your project. Everything's going to come out of this, the pricing, what the end product looks like, the budget, that's all coming from this document. It's very important that it's right. That's the way that we police Waterfall. If you don't get the document right, you can't expect a Waterfall project to work out well. Again, I can't harp on that point enough.
Finally, in terms of how we do this, the proposal should be the shortest, easiest document that you receive. We prefer our proposals to be one or two pages. It basically says option one, two, three, budget, budget, budget. There's no need at this point with all the time that's been spent to have a 30 page proposal. You don't need to have a giant about us section with all the pretty headshots. You don't need that because you already spent time with us. It should just be these are the options, this is the recommended budget, here's a timeframe, these are some potential terms, and that's it. If you're getting a proposal more than one or two pages on top of a discovery report, it's probably just a lot of fluff.
Like I say here, the longer the proposal, the less thought probably went into it. Again, going back to how you procured services in the past, if you've had a couple of phone calls with someone, maybe half an hour here, 45 minutes there, and they send you a 20 minute proposal, it would be crazy for you to think that that was made all for you. It definitely wasn't. It was made probably something off-the-shelf that they had and they just did a copy and paste, put your name in there, and that's how you got to where you ended up. 
Really quick as I start to wrap up here, and again, any questions, feel free to send it. I see a couple came in. How do you get the most value out of this? Well, first off you're paying for it. This is always a paid service. Ask questions. Any discovery's going to have the highest level people that you're probably going to deal with and it's also going to include, if the agency does it right, the project managers and the actual artists that are going to work on it. Ask the questions. The people are there at the moment. Ask challenging questions. Try to get as much insight as you possibly can because this is your vetting period in a lot of ways as well.
Don't hold back on future plans or potential pivots. I have another slide. I'm going to talk about that in a second. We understand business. We're entrepreneurs, we run small business, we deal with many different projects. We understand what it is you're trying to do. Share as much as you possibly can. Sign an NDA if there's something that you have to keep protected. No agency that I've ever heard of refuses to sign an NDA. Share as much as you can because it'll avoid the got yous. 
Again, again, again, the purpose of discovery is to make these Waterfall projects as secure as possible so that there aren't disagreements in the future. Agreements prevent disagreements. This is the same exact thing. Waterfall is easier to sell to the people at your company. We need to make sure that both sides are protected, both parties are protected. You know what you're getting, we know what we're selling. To do that, you have to give as much information as possible. 
When you get the findings document, review it and show us that you reviewed it. Send it back redlined. Send it back with track changes. Turn it on so that we know that you were in there, because there has been times that we've gone through this and then people come back and say, "Oh yeah, the document's good," yet that can lead to disagreement later. We, again, want to make sure that we do a great job for you. We want to do everything that we promise. We just want to make sure that both parties are aware of what the promises were, and that's how you drive the most success.
Speaking of the future, again, you're undertaking a serious project, you're paying money for the discovery. This is something that you have to take very seriously, but again, we're probably building the foundation for where you're going to be going in the future as well. Always be prepared to iterate. Remember we talked about the MVP. On a development project, we want to have an MVP out there that's something that you can build upon, that's a stable foundation that lasts you for many years to come, but be prepared that the future will bring changes and it will bring development on top of the MVP. 
We avoid those future roadblocks now by going through this process. A lot of what we do from the very first introductory call is not just thinking about the initial project, but thinking also about where are you going to be one, three, five years down the line? I tell our custom CMS customers I'm looking for a minimum five to seven years of lifespan on the CMS alone. We have examples eight, nine years of customers running on the same exact platform. Reason that we're able to do that is because we have an understanding from day one of where it is they want to go. 
Now, I get that there's pivoting and businesses change, but as much as we can know in the beginning, we can prevent massive redevelopment flaws in the future. Actually, we just had a customer this morning who started out as an informational site and then we uncovered, well, it's going to be a little bit more complex. They want to have a transactional community area. Well, suddenly the technology requirements for this project could potentially change, so these are things that you can avoid, again, by speaking about the future in the present. 
With that, I'm going to take a quick drink here. Send in any questions that you might have. I see a couple. Send them through. Our first one, actually this is a great question. Can you do discovery for an Agile project? From Jason. Yeah, absolutely can. I think that's important to do that as well to build out a road map. With an Agile project, discovery is a little bit different. It doesn't have to be perfect on the specification, but it can definitely have, if you remember a couple of slides before we talked about recommended implementation, you can go through the process, have a recommended implementation, and then break down what your first series of sprints are going to be. 
Again, Agile is where you take a team and you're buying access to time and it's going to be goal-oriented. The purpose of a discovery there is to figure out what's the longterm plan and future vision for the project? What's the MVP look like? Again, breaking it down into reasonable phases and were called sprints, and then going from there. You can definitely do it. It looks a little bit different. Typically, the first sprint or the first half a sprint would probably be dedicated to this type of work anyway, but you could do it definitely before you begin that type of project. 
I'll follow up that question saying could you actually not know the methodology when you go into discovery? Yeah. You could definitely leave that up in the air if you wanted to. There's no reason why you couldn't. It would probably be beneficial to approach it as a Waterfall type of project and then somehow find the way to go Agile. That would actually solve some problems, but yeah, you could definitely come in with a little bit of uncertainty about the methodology. 
Another question. I was just pitched this discovery process. What's a decent budget I should prepare to spend? Well, so again, it's made specifically for you. This process is made for you. Typically, we have some, if it's done virtually over a phone call, for example, and we predict that the findings document's going to be an eight to 10 page thing and could start as low as $1500, $2000. We've done discoveries that go up over $20 thousand. Again, it's based on how many people are we meeting? Are we on-site? Do we have to come out by you? Are you going to come to us? Can it be done over a virtualized line? How many participants? And again, the findings document. The larger the findings document, that's obviously going to drive cost as well because we have to produce this document. 
Sometimes people scoff and they're like, "Hey, that's a lot of money." What you have to think about is the value that you're actually taking from this project. You're taking our recommended implementation, how you're going to build it, you're taking the full specification. There's a lot of value that's to be extracted based off of this process, but I do believe ... I'm getting too defensive about the pricing. Again, it's worthwhile to do. You're extracting a lot of value and you're going to save that money in the future because if you go into a project without a good plan, what's going to happen? You're going to blow it later on with redevelopment and confusion. 
I don't see any other questions. Thanks for joining me. Really quick, we're going to do another webinar. I know this one I had to reschedule two or three times. It gets busy around here, that's my fault, but I am setting this one on the calendar. It's going to be Thursday, July 6th, and we're going to talk about making the case for custom software. Check out my blog post. I'm not sure if it was last week or the week before, but it was about the dirty secret of off-the-shelf software, and we're going to be delving into that. 
I would definitely read that post and maybe ... Well, this might be a little bit more controversial, but I hope you join us. The signup for that should be available in the next couple of days. I'm sure we'll have it in our Friday roundup. Remember, if you're not on our mailing list either, and you should be if you signed up for this, every Friday we send out a new blog post. I write them myself. Typically, they're going to be talking about custom design, custom development. This week's topic is to be determined, actually, but I promise you we'll have something by the end of the week.
On that note, again, this is the address for our blog. We also put out a lot of video content. All these webinars are actually ... We keep them on the website, they're archived, and I'm looking here. I have one, two, three, four. I think this is number six for us this year. Some of the past ones are Designing and Deploying a Secure CMS, Modular Web Design. We talk about website redesign tips. We have a great webinar about the CMS of the future, and then we talk about solving business challenges with custom web development, each one about the same length. Like I said, I talked quickly to try to get you guys back to your day, about 35 to 40 minutes per, so definitely check that out. 
We have a bunch of downloadable e-books. How many do I have? Let me take a look. I have ... Oh, it's loading kind of slow. There we go, eight or nine. Eight or nine different e-books here that you can download. Actually I'm wrong, I have 11. Check those out, a lot of stuff about custom development. We have an e-book about the CMS of the future, which is something that we're pretty excited about the new architecture going into these CMS platforms. Have a look at that. 
Again, if you need to ever get in touch with me, there's my phone number, just call up, ask for Pete. We're located right outside of Manhattan, relatively close. You ever want us to come visit, happy to do it. With that, thanks for joining. I'll see you guys soon. Take care.