Writing code is an art. Architecting a system is an art. Making a website usable, simple and intuitive is an art. But all art has its techniques, rules and procedures that assist the creative process in achieving its greatness. Planning software development is one of those processes which, if executed rigorously, yields incredible freedom for the developers, project managers, designers and system architects to focus their creative efforts on what matters —the end-goal.
I have observed many projects where clients, for a variety of reasons including the false belief that “We don’t have time,” have failed to follow the development process. The results have typically translated to one of the following:
- Being over budget
- Missed timelines
- Poor Usability
- Missed Functionality
- Re-work due to misinterpreted requirements
This is only a short-list of some of the many things that could go wrong. Not “having time” is a poor reason not to spend a little bit of effort figuring out exactly what’s needed. This doesn’t mean that we have to tell the developer, system architect, or designer what to do, but rather it’s giving them a target to hit. The path to the target is where the developer, system architect, and designer use their artful expression to achieve the requested functionality. A clearly defined target is what’s needed for these folks to have the freedom to meet the client’s demands.
So what does this process look like?
To describe it fully will require authoring a series of articles that go deeply into the details. For now, I am going to do a gentle introduction, a high level overview, of what the process looks like. In general terms, it is structured like this:
- Meet and Greet / Getting to Know Each Other
- Overview Interview
- Scope and Terms Negotiation
Each of these phases is distinct in what transpires while we are in them and what comes out of them. They’re essential for a successful development project (I’ll explain why in a moment), and at times there may be some iteration among them. Let’s take a moment and discuss each phase, their virtues, and why some of them are a drag.
Meet and Greet
Meet and Greet or Getting to Know Each Other is about ascertaining if initial trust or grace can be bestowed among all involved. We listen carefully to our client and speak only to demonstrate that we know what they want and that we are capable of meeting their needs. On the other side of the table the client carefully listens to determine if we have not only the competence to meet their needs but also if we have the character and demeanor which will lead to a positive experience. It’s a time to give advice, speak candidly and openly about the project. In some instances, because of previous experience between the parties, this portion of the process is shortened. At times, it requires us to build the relationship. It is essential that we truly get to know the people involved. Why so much fuss about this? I believe people want to connect. People want to feel that they are understood; it helps develop trust and credibility in the relationship.
The Overview Interview is where we take the time to discuss, at a high level, what the client is trying to accomplish. This conversation typically happens immediately after the Meet and Greet and at times may be your first officially scheduled meeting. Both parties need to walk away from the meeting feeling confident 1) that we understand what they want, and 2) that they understand that getting a more precise estimate requires an in-depth business analysis. There may be cases where the project is so simple that the overview interview yields the scope. However, this isn’t usually the case. Getting the client to understand the value of the discovery is imperative, because, it’s out of this discovery process that we really get into the details of things—the why’s, how’s, when’s , where’s, and who’s of the project.
The Discovery phase is described by some as discovering the devil in the details, but I prefer the phrase, “God is in the details”. This is where we surface all the opportunities that must be seized and the challenges that must be conquered. It’s about understanding the problem well enough so that, as my partner, James Ring-Howell says, “we could almost do their jobs ourselves”. It’s this deep level of understanding that allows us to come up with innovative solutions, and enables us to prepare a decent scope of work.
Scope and Terms Negotiation
The Scope and Terms Negotiation requires that out of the Discovery phase we have scope in black and white or in TP (no it’s not toilet paper, it’s Target Process). Target Process is a tool we utilize for tracking our projects but also, can be used to record the scope of what’s intended to be built. Regardless of what tool you use the client should walk away with tangible documentation that has the details of what is to be done. This document will be used by that client to determine if we got the details right, and if there are any changes that we need to consider prior to execution. But what about the terms? This is also part of the negotiation. It isn’t just about what we are going to do, but also how will it be financed. The posture during this process should be one of, “How can we make this work?” To do that you need to know what your utility costs are and what you’re willing to give initially so that all can win later. Discussing this in detail is another article which we will write later.
Execution is about getting from 0 to delivery in the most cost-effective and expeditious way, while still providing a loveable product. This is where competence, integrity and creativity come to play. This is when the art happens. One thing that’s crucial during this phase is to keep communication channels open, so the client is never surprised and kept informed of all progress and any challenges.
Hand-off is the one point at which you can boost your credibility or erase it completely. If you don’t plan up-front to be heavily involved during the hand-off you will find yourself short changing yourself and the client. These things we build are complex and require a delicate, methodical and rigorous hand-off effort. Some clients call this the “on-boarding” process—if they have some experience in these matters. More often, though, it is our responsibility to educate the client that this is coming and they must allocate some time. Successful hand-offs require an all hands on deck approach. The developer, architect and designer must drop themselves into the background while the operational folks on the client side take the lead. It’s exciting to see this happen. It’s a time where lots of patience, lots of coaching, and lots of communication must take place.
If all goes well a celebration is in order—everyone involved can connect and reflect and celebrate a successful launch. As a hint, the development house should pick-up the tab… Huh? Oh wait! That’s us!
Now, I‘m going to celebrate that this first article is written. Keep your eyes on Fireside for the next article about the process.