As every good developer knows, a process is crucial to the success of your project. Without it, clients run amok, design changes seven times, development never has a clear objective, and the project becomes an all around disaster. Process is important, it keeps everyones eye on the prize. At Zenman, I've spent the past 3 and a half years cultivating a process that I believe works quite well.

One thing that I want to preface here, and I'll refrence this point a bunch, is that your process is never EVER perfect. I can't think of a single process that I've been a part of that didn't have some room for improvement. So keep in mind, the fact that you're even trying to lay out a process, is a step in the right direction. You're going to change it, iterate on it, and ultimately improve upon it.

Setting the Right Processes in Place

When first developing our process at Zenman we had to establish exactly what it was we were trying to accomplish. Where are we headed? What exactly is that prize we should be keeping our eyes on. What it came down to was simply the fact that we wanted a process that provided designers, developers, and business with all of the information that is needed for the project right off the bat. Leave no stone unturned.

The first step in attaining this goal was to hold a discovery meeting, which for Zenman, is our first deep dive into what the client is all about. This meeting incorporates every member of the team for this specific project. Everyone from Project Manager and Sales Exec, to Developer and Designer, all the way up to the CEO sits in on this meeting.

We incorporate everyone in this meeting for a very specific reason, and that is because without full immersion in the process, your process is more likely to fail. Having everyone participate in this meeting gives us all the preparation we need for the project as a whole. And not only that, it gives each department insight into the other departments processes and methodology. This then helps sales people to sell better, because they understand our development process, and can explain to clients more readily and knowledgeably about how that process works. Everyone benefits from having a high level understanding of how the other departments work, thus creating a more seemless project and inevitably a better product.

Just to give you a little insight into our discovery process, from a development standpoint, during the discovery we ask some technical questions like where is your current site hosted, where is your domain registered, how are your emails set up, and how do we access your google analytics. This gives us the power to complete steps within our process that are both immediate, and further down the line, so that a back and forth does not need to occur between developer and client. Having a clear goal in place makes a project ridiculously more manageable.

Is it Scalable?

One of the best things about the process that we implemented at Zenman is that it is effective for projects of all sizes. From Fortune 500 companies down to startups, our process works. There is no more tempting time to skip out on process then on a small project. This is where you kind of have to reign in the project managers and sales folks. At this point, a PM or AM will try to tempt you with promises of gold and mir to break process and get the task done in record time.

DON'T DO IT! Sticking to the process may incur a little bit of extra time up front, but for the love of God it has the potential to save your ass in the long run.

Nothing like an example to help justify my claim...one of our steps in the process, almost immediately after our discovery meeting, is to run a smoke test on the clients server. A smoke test for anyone interested is just an automated test that runs through a series of tasks to ensure that, in our case, the clients server is set up to handle a WordPress installation. There have been a few times where the process doesn't get followed, the client drags their feet in getting us hosting credentials, and all of the sudden, it's time to launch the site! Hooray right? Not exactly. I've tried to launch to a server where a smoke test was not ran before and run into castrophic problems...it's running on PHP4...ssh isn't enabled...the server was bit by a PC and is now a windows server...awful awful terrible things like that. And because of these things, the site didn't get launched, and the project delivery date had to be extended, sometimes as long as weeks after the initial go live date.

If process had been followed, we wouldn't have run into these issues, they would have been resolved while development was happening, and the site would have gone live on the day it was supposed to.

This is where I'll end the post for now. Stay tuned for more like this as I intend to turn this series of posts into a talk that I'll be giving in August at Refresh Denver. Check it out and RSVP if you're interested!