Top 3 mistakes when working on digital projects

Have you engaged in a digital project and not gotten what you wanted?

Or have you been engaged in a digital project and suffered from the two most feared words in a developers mind: Scope and Creep.

The definition of which is to slowly go beyond the originally intended features and functionality of a project’s scope without additional budget and driving you bat shit crazy.

Well I have. Many times. I want to share with you the last time this (ever) happened to me and how I fixed it.

To provide some framing, this project was for a non-profit. It was to design and build a movement to encourage schools to engage their students with gardens and cooking in addition to their core curriculum.

It was a fixed fee, fixed scope Drupal-based project with three phases: Inception, Design and Build. There were other companies working on the site. A visual design firm, a user experience firm (us) and a development partner subcontracted by us. We were responsible for defining the user experience and managing the execution, “Agency of Record” as it’s called in advertising.

To start, the client was pretty awesome. An illustrious founder, a worthy cause and passion for food and education. We were excited to get an opportunity to work on this project.

Before signing the contract we took our time to understand the scope and their needs. We also consulted our development partner on the cost to build the site and make sure everyone understood their roles and responsibilities. We scheduled the right meetings with the right stakeholders and crossed our t’s and dotted our i’s. It all looked awesome. On paper.

So let’s start with the challenges:

One of the first challenges was with the design firm, they dropped the ball on the design. After some initial concept conversations the execution fell short.

However, we were able to move forward with our process and doing our brand definition, user definition and goal-setting work sessions. All went well and we moved to the next step which was to create a site map. We prepared our first draft and presented it during a work session by putting it up on a chalkboard using large 3x5 Post-it notes. This gave the primary stakeholder a chance to contribute to the process and give instant feedback. Yeay!

We then moved to the wireframing process where we began to give the project definition. And here is where one of our core mistakes was made. We were defining features and functionality without a Drupal developer in the room.

These leads me to one of the most common mistakes teams make.

Mistake #1: Designing without a developer present.

What did we do wrong? The original requirements on paper defined what features the client wanted, such as “Profiles, Recipes, Search, Mapping etc.” Many, if not all, are fairly standard feature modules in Drupal. So our development partner was right when they said “sure, that is easy”.

But, and a BIG but, the document was “low fidelity”, meaning that it didn’t expand on the more detailed functionality for each of those features. We had agreed to “dig a hole” but not on “how deep” we wanted it.

Before you think we were stupid, let me tell you that everyone does the same thing.

“According to new research, success in 68% of technology projects is ‘improbable.’ Poor requirements analysis causes many of these failures, meaning projects are doomed right from the start.”

—TechRepublic

Another earlier study puts the number at 62% — “CIO.com cites a Dynamic Markets survey of 800 IT managers, reporting that 62 percent of IT projects fail to meet their schedules.” It cites “not taking into account the time required between design and development…”

So we basically did what almost 70% of you reading this have done. More importantly, I knew that this would happen. That the tech bid was going to change once we did higher fidelity design. So why did I move forward signing a contract? If I knew, wasn’t it my ethical responsibility to tell the client?

The more important question you might be asking is: Why does this even happen?

1. The interests of the organization and the agency are not aligned. The agency needs you to close new business and you know the client won’t approve a variable scope contract. So you either decline the job or you Hail Mary it and pay the bills.
2. “You could have done a more detailed job scoping it!” Sure, but that would require you to do a third of the work up front, without a guarantee you would get the job.
3. “If you are an internal team you don’t have any excuse, you should be able to do it!” Right? Nope. The IT department and the marketing departments are separate and have separate budgets and a bunch of other projects going on. The marketing dept hands over a document (thin) and some designs and asks the IT dept to give an estimate… I will spare you the rest of the story. Let’s just agree that it’s messy, drawn out and inaccurate.

Welcome to your own death.

Mistake #2: Sign a contract for an entire project using only business requirements to design and build.

“What is wrong with this?” you might ask. This is how it has always been done. If I need a kitchen built, I give you my requirements, you give me a quote and we build it. For those of you who have gone through a kitchen remodel you know how this story goes.

There are many, many problems with this and I won’t go into all of them. I will focus on one problem: unless you are buying a “five page, pre-designed template, with 10 hours of coding for $699.99” you are NOT buying a website. You are buying a team to design and build a piece of custom software, to solve some serious business or innovation challenges. The work that needs to be done for this is nothing short of complex, important and “lord have mercy on the person left holding the bag at the end of that dance!” Ok I am mixing my metaphors and switched to southern church lady, but you get my point.

Let me make the problem less dramatic and clear: You are buying services not a washing machine.

Again, setting up your own website on Virb (Amazing service from MediaTemple) for your small business (you at home) is a different story.

This blog post is not about that. This is about the Division of Fox that needs to set up a content platform with commerce and fan services based on an existing sports brand and user base. I am talking about the city government that needs to have a portal for their constituents to access city services and government officials. I am talking about the publicly held manufacturing company that needs direct ecommerce set up while still preserving the relationships with their existing dealers and retailers.

What should we have done in this case? What would I do differently?

If I had to do it again I would go back (in my Delorean) to before the project and write this blog post and send it to the client.Then I’d convince them to do a separate ”Inception“ (Discovery) phase for $30-50k where we would do the brand definition, user definition, goal setting, create a site map, and build wireframes. I would then show those to the developer and get their input on how we could do it inside the clients remaining budget.

Boom, there it is.

Mistake #3: Sign a contract with a tech partner without doing a discovery phase first.

Ok, we are back on the original timeline. That means I never went back and never wrote this post in the past. (Because I forgot where I parked the Delorean. I think it was in Pomona, sigh.)

So I did sign the contract with the tech partner without doing a discovery phase and we moved forward. So what happened? Let me tell you what happened.

We got through the architecture phase with flying colors. We figured out all of the details, the features and functionality that the client wanted. It looked really good. We were all so excited we forgot that we still had to build it. So alas, after the features and functionality had been signed off and approved by the happy board of the non-profit and we all celebrated our awesomeness, but our spirits were dampened by the “Wait a minute, this is going to cost three times what we quoted you…” surprise from our development partner. (Insert screeching tires sound effect here.)

So what do you do at this juncture?

You can:

1. Yell at your development partner and demand they build it for what they quoted and signed up for.
2. You can tell the client that it’s going to cost three times as much and that they need to go back to the board and ask for more money.
3. You can cut the difference in the middle and have everyone be pissed at you.

What is funny is that these are exactly the three things most people do. Here is how it usually goes:

1. You yell at your development partner or IT dept head. They yell back at you to go tell your client or stakeholder that they need a bigger budget.
2. You go back to your client or your stakeholder and you tell them that you need three times more money.
3. The client is pissed, yell at you back and tell you to go get the cost reduced by IT and IT tells you to cut scope.

In the end, you’ll end up somewhere in the middle and you end up negotiating 20th Century style like you were at a damn bazaar in a foreign land negotiating over the price of a billy goat.

No one is really happy, your job is stressful and you pretty much hate your life.

So what did I do?

Ok. That is a good question. Here is what happened next:

1. I did not yell at our development partner. First because I am far too gentile of a soul to do that and second because I knew they were right. I had been around the block enough times to know that, and more importantly I knew this was coming so I already had a plan in mind.
2. I explained the nature of the problem to the client in a very well articulated Powerpoint presentation that I helped our producer prepare. I also offered a solution to the problem if they were willing to try it with us. (Wouldn’t you like to see that Powerpoint?)
3. I offered a solution where all our our interests would be aligned and no one would get screwed.

What was my solution?

My solution was to switch things over to Agile. Specifically SCRUM. What is Agile? Agile is an iterative software development management process that favors iterative development focused on meeting business objectives, not specific features and functionality. Meaning we knew we wanted “profiles” not exactly how complex the profile functionality should be. The reason being that the business goal was for community members to share recipes and curriculum with each other so that the non-profit did not have to do all the work. The community would build itself. So by separating our goal (the community building itself) from our specific wireframes and comparing our goal to what the Drupal platform had out-of-the-box (which required the developer in the room), and then cutting out the differences, we would save many hours from development and therefore from cost. We ended up digging just as many holes as the client wanted but just a lot more shallower holes.

So what happened at the end? Did everyone live happily ever after?

Yes. I am happy to report that everything turned out well. We applied Agile effortlessly (I am a highly experienced Agile SCRUM master) and after some initial shock during our planning sessions, we were able to build almost everything that the client wanted in the original budget. That was part of the deal in the PPT. I told them to trust that we would get most of their important features built within their original budget. By the end of the originally contracted budget we only had a 15% difference between the original estimate and what we were able to build. By this point, we had build so much and the client was so happy that the board easily approved the additional 15% budget increase and we added one more sprint to the engagement.

This project marks a turning point in my journey. At this point I said to myself, no one should have to go through this. There is a better way to do this!

Then and there I made the commitment to helping teach the world a better way to do software projects that you now know as The Skool OS! The standard system for successful web projects!