The dot-com that almost ‘dot-crashed’
Many years ago, I was a part of a design agency that was building its first ‘dot.com‘. After eight months, we delivered version one and to be honest, it was full of bugs and we were all exhausted from weeks of late night coding. That first version was ‘code thrashing’ at its finest. We threw code at the requirements the project stakeholders were dreaming up and the frustrating part was that those were changing… every day.
Nothing was documented except for madly scribbled notes and any commenting that we had time to accomplish within our code. Beyond that, all decisions were made during coding sessions and ad-hoc hallway conversations. The product was miserable. Crashing servers, lost data, mysteriously vanishing items in customer shopping carts… it was ugly. But no rest for the weary, the boss-man came to us saying he wanted the next release to happen in six months. We hung our heads in defeat. How in the world were we going to do this?
I rallied the team together to discuss how we were going to hit this next deadline without the same issues that were in the current version. Throughout our initial team meetings, the same theme kept popping up, we did not have any documentation detailing what we were building and why. Being new to formal software development, we didn’t know what we didn’t know so we started researching. How do we collect what the business wants, and even more critical, what questions do we ask? We looked at what other software development shops were doing and pieced together a process we thought would work for us.
We came up with our own process diagram that we affectionately call the “411 Method” which was presented to the stakeholders. This method was a 4 phase, 11 step software method that gave us a software development process that included documentation, quality assurance (QA) and testing. We didn’t see a downside to this process, except one thing. We wanted two months for meetings, discovery and documentation and then 4 months to build out the solution.
After presenting this process to the project stakeholders, I thought they were going to die. They laughed at the idea. We had just spent 8 months trying to figure out version one and we delivered something less than spectacular and now we wanted only 4 months to code the new version? It was one of those decisions in my career where there was a rush in my ears and sweat trickling down my back. But I stayed firm as I was representing my team. The management team finally caved and gave us our timeline. Now we had to deliver.
We spent 8 weeks on discovery. We dissected the current version of the site and kept requirements that made sense and threw out the rest. We met with the project stakeholders and documented any additional requirements that they desired. We submitted those documents for the management team for approval and we were off to the races.
In short, we delivered on time, with minimal issues, and with a complete version two solution that covered all of the project stakeholders needs. Version 2 of the project is when we started making money as well so we were all very happy with our new process. The main difference between version one and version two was that we took the time for discovery. We took the time to ask questions, communicate concerns and come to an agreement on scope, resources and the timeline. I’ve never forgotten how important discovery is to agencies, projects, clients and my sanity.
What is Project Discovery?
Project discovery is taking the time to find out what we know, and don’t know, about a client’s business needs for a specific project. It’s also an effort for the client and the agency to further develop their working relationship before a project even begins. Many times, the discovery process finds weaknesses in the client’s understanding of their website and exposes details that they may not know about their business processes.
Project discovery can be as simple as an online form collecting information from a client or as complex as multiple day workshops where an agency will meet with the client to dive into their business requirements.
Notice I never said ‘how’ the work will accomplish things. Or with ‘what’ technology the solution will use to get the work done. That is not the core goal of the discovery process. On smaller projects, those answers could be a part of your discovery document in a recommendations section.
Larger projects may require a separate set of documentation called technical requirements document that detail how a solution would be produced and with what technologies that solution will employ to satisfy the business requirements in the discovery document.
Discovery is a critical part of any website project. Some agencies call discovery different names like Phase Zero, Pre-Planning, or Recon. It doesn’t matter what they call it, what matters is that it is accomplished.
Resistance to Discovery
The project discovery phase is often seen by agencies as something that clients don’t want to pay for but that they have to accomplish. Clients look at a “Discovery” line item on their estimates and ask, “What am I paying for now?” The answer here is to agree that discovery happens in all projects and clients need to be educated why it needs to happen. As an agency, it is your duty to educate your clients on the discovery phase and the value it brings. Without discovery, your damaging your relationship with your client and you are also putting a burden on your staff that will result in endless evenings, burned-out employees and high turnover.
The discovery phase of a project is one of the most important efforts a project team can accomplish because it lays the foundation for a project. The documentation that results from discovery is used by project managers, programmers, designers and the client. A good discovery document can be taken to any agency and used to help build out a project.
The discovery document is also organic, it changes throughout the project. Elements are added to it as they are uncovered and the project’s phases can be planned using the items identified in the document.
Why is discovery important to my project?
There are many people I have met at agencies that cringe at the thought of charging someone for a separate discovery phase for a project. But here’s the thing, you are already doing it! Many people I talked to have it built into their sales process and they never recover any of the professional consultant services they give the client during that sales phase. Time after time, these agencies spend hundreds of hours on proposals for clients that dig deep into the client’s business processes. Then the agency documents those and creates a proposal and estimate for the work required to get the project done. Guess what they just did? They provided a discovery document that the client can now use to shop to other agencies! I’ve done this countless numbers of times first-hand and it has never resulted in winning the job.
Any project you work on requires discovery. I If you are a potential client of an agency and they do not have a discovery phase, you should ask for one or find an agency that knows how to do them.
AGENCY BENEFITS
- Transparency in the project
- Revealing business processes that are directly and indirectly affect the website
- Creating a foundation of open communication with your client
- Creating a canonical document that can be referenced during the term of the project
- It’s good for your agile processes you use for your project
- Heads off scope-creep very quickly.
CLIENT BENEFITS
- Forces the client to think about why they want what they want.
- Discovers processes that may not have been thought about
- Creates a deeper relationship with the agency
- Creates a clear pathway to site releases, including future phases
- Client will receive a more accurate estimate on the work
- Allows for the addition of scope items in a way that is ordered and efficient
Discovery happens…
The discovery process is not an ‘if’ but a ‘when’. It happens on every website project that exists. There has to be answers to why a site exists. What will accomplish for the client?
An agency needs to get paid for their consultant hours and a client needs to understand that project discovery is not a bad word but paves the way for a smooth project implementation.
ABOUT THE AUTHOR
Erik Kulvinskas has over 2 decades of web development experience that started way back before front-ends, back-ends, ‘dot-coms’, and social media. He loves making things easier to understand and more efficient to use. He loves spending time with his family, cycling, and volunteering. He enjoys empowering others to be their best and leading others by serving them.
