Please read the previous post here Things Change to get context
Let’s briefly look at what the typical client expects at the end of any project. (This is not meant to be a comprehensive list but a summary of the basic items a customer expects. If you think something should be there please comment on this post. I am always looking for feedback.)
- They would like what they like. This may or may not be defined at the start of a project.
- They want to know how much it will cost. This almost always must be defined at the start of a project.
- The cost has a max. This is ALWAYS true with everyone.
- They would like to know when it will be done, but unlike cost, when it will be done may or many not be as important.
Like what you like but what is it like?
If everything was a “Yes” and “No” projects would be simple. If there wasn’t complexity and, more importantly, subjectivity, projects would be easy to plan and deliver. The problem is the following:
Client: “Dear Agency, I would like my website to look like MegaCorp.com”
Agency: “Ok we will model some designs to make it look similar to MegaCorp.com”
Client: “Please tell me how much it will cost to make it look exactly like MegaCorp and how long it will take.”
If the agency is not careful they will start the project already failing. The “want” in a subjective environment is the hardest thing to attain and contains the greatest risk. The “want” is something that a young designer could deliver quickly or a seasoned designer may never deliver. The point is that it is very subjective. The “want” is the biggest risk because you don’t know what anyone really wants until you start working. The client may have many ideas in their head about what they want and those ideas change every time they look at the new website. For the agency, this means it is a moving target that can only be achieved once a design is locked down, agreed on by both sides, and signed off on.
To further complicate things, if the design is something new and if the designer comes up with something revolutionary and fantastic, the inherent complexity of new design will most likely take longer and be more expensive. If they stray far from what Magento can do, the backend estimates for this design will be greatly inflated. This leads some clients to question why. It is the agency's responsibility to have a developer sign off on designs even before a client sees them. If you take a category page for example; The default category page does 80% of what most clients want. The designer may have great ideas but some of the functions they may suggest would require extending the basic functionality of Magento and thus add cost to the project.
You can see how quickly the design portion of a project can get complicated and you can see why it is important to move from the subjective to the objective. If you have a design that shows what the look will be and then describes what the look will do then you will be able to gauge the effort of that feature much better than just “I like the Google.com page”.
No Free Lunches
I recently met with a large enterprise agency and they stated they build in 40% risk to a fixed bid project. In fact, if any agency is not building in some risk then they are providing a disservice to their team as well as their client. The time and materials model works the best if there is a broad budget of what is trying to be accomplished. The fixed bid is a myth and what fixed bid means is the following: I have a bunch or requirements that will never change and I will not want to add anything over the next 12-16 weeks. I have never had a software project where nothing changed. This is the reason that fixed bids are full of risk and that risk is built in. I will stress, if you are a client and reading this, don’t think the risk is something that you want to add. The risk is for something that wasn’t known but could have been, should have been or, at some point in the project, became known.
The idea of a broad budget is, in my opinion, the best way to approach a project. You can section off specific buckets of work and then scope out that work. The risk is balanced over different areas and it will allow the client to see where changes happened and how they impact the project. Design, Development, DevOps, and Data are all big buckets that can sit at the top of your SOW. These buckets can be pared down into smaller segments which will further reduce the risk.
The Final Countdown
Of course, everyone wants to know when their project will be done. I think this is the most overlooked area. Once you have hours estimated you can by definition plan on when those hours can be worked. From this, you can plan on how long it will take to carry out the work. Finally, you can build in the time that tickets go back and forth with clients. Once you have that formula you can come up with a launch date. The launch date will help to hold everyone accountable. It not only holds the agency accountable, but it also holds the client accountable to what they need to complete.
Tomorrow, tomorrow, I’ll finish tomorrow
As we just discussed, the “when” can easily be estimated and the more you report the “when” the better everyone understands what is holding things up. So the final launch date is set, we are moving towards a date and the client decides they want to wait.
What do you do?
Next week we will look at the Agency perspective and see how the waiting and other things can be resolved.