Things Change - The Fix Bid Project

This entry was posted on October 10, 2016 by Brent W Peterson


Things Change

by Brent W. Peterson Directory of Customer Experience.

A continuation of my Customer Experience series.
At the end of the day, the client wants to have their website completed in the way THEY want it. The trick is when you start your project things change. Things change and whoever starts a project as a fixed bid and will hope to come to the end of a project with what they started is only fooling themselves. Things change from the client perspective and things change from the agency perspective. The bottom line is that these changes will affect your project and the sooner you can wrap your head around this concept the more successful your project will be.

The Basics

Client wants something -> Agency delivers something

The success or failure of a project resides in the middle of these two things. What we can do now is to continue to break down the high-level items in any project. From these items we can ask questions about what is important to getting from A to B. How we navigate that road and how we report where we are and the road blocks involved will determine the success of the project. Let me add that the length of the road and the amount of work that needs to go down the road will also contribute to the success of the project. If the project is projected to last 2 years there is a much higher probability of failure than a project that will last only 2 weeks. The ratio of work to time is an important number to look at. The risk of a lot of work and a short amount of time is that something has to be given up. One cannot simply deliver everything in a given time when it is impossible to do everything in that time.

Let's break down the project at a high level

  • Client wants something
  • Client communicates to agency what they want
  • Agency digests what they want to communicates back to client what they will do and how long it will take to do it.

The “want” in a project is not always 100% to everyone. The “want” is sometimes all determined at the beginning but most likely wants will trickle out during the project. This is the biggest reason why Agile is the best approach for project management. So the next question is “How do I translate what the client wants into what we are going to do?” This communication is the key to the success of the start of the project, but continued communication and a partnership point of view is how the project will finish successfully.

The how long it takes to do it is a number that will cause great contention later in the project. Why? Because what the client expects will be done may be different than what the Agency thinks they want. To further complicate things we have time that is lost because people need to eat and sleep and we have weekends and vacation. So 80 hours of work doesn’t necessarily mean it will be done in two weeks. It is the responsibility of the agency to communicate that the time to complete the 80 hours will be compounded by the fact that there may be a time that work goes through Q/A and the Q/A team will need time to review and look at tickets. (This is just an example, but there are many other factors that will contribute to this time) What we do know is that we can come up with an average of how long it takes to complete 40 hours of work. An example is the following:

40 hours = 5 man days. The 5 man days will take unto 15 days to complete because each item that makes up those 8 hours of daily work must be reviewed by a project manager, worked on by a developer, Q/A by a technician, code pushed around by a DevOp and reviewed by the client. All these steps assume that everyone will take them in serial order. The client can argue that the agency can simply put more developers on a project. So theoretically a 40-hour job could be done by 5 people in one day. This assumes that the client also has enough people to review the work being done in that day and that the work CAN be done in parallel. It is at this point that the agency has the responsibility to communicate truthfully to the client that something CAN’T be done in the timeframe the client requests.

Next week we will dive into the Client.