In our first post on this topic, Red Lobster Eyes With a Happy Meal Wallet, we began the discussion of the difficulty involved in estimating projects for startup companies. We took the time to chat about the nature of the bright people with big ideas who choose to try something new on the Internet. Our main point was that Big Idea people often underestimate the time and money it takes to complete a project. Today we will talk about one of the principle pitfalls that arise in reaction to lack of resources.
That a start-up company is underfunded is not news to anyone. Having started a business myself I'm well aware that most of the time a start-up owner is doing what he is able to do, not what he wants to do. When a big idea person comes to me with a list of features I know I will be tasked with helping this customer see the possibilities while keeping his feet on the ground. My first goal is to create a list of the core features that are essential to the site's success. I suggest to the customer that he (or she) put his money into making these core features rock solid, thoroughly QA'ed, scalable and extendible.
Sometimes this results in a great application with foundational code that becomes the bedrock of all future development on the product (let's hope anyway). Often however, the customer focuses intently on trying to squeeze more features out of the budget. In other words, cutting quality in favor of quantity. In fact this is a somewhat natural outgrowth of my next point. Most big idea people really see the totality of their project or product as a set of features - not as a "system" with lots of interlocking parts. The customer's true understanding of the project centers around the "screens" that you build for him or her. This is pretty obvious when you think about it. Consider for a moment that the customer will probably never see most of the code you write for the project. Instead, he or she will interact with the system in the way you designed, using the screens or applications or widgets that are built for customer interaction.
Because of this screen-centric view the customer may have extreme difficulty understanding how development time breaks down. This is important to you as well as the customer. When you present them with an invoice for $4,000 or $5,000 for a single feature they will have some questions about what they are getting for that amount of money.
Let's take a simple messaging system as an example. A short description of our system is as follows:Given that explanation, here is what the customer sees.
We as developers might see the following tasks or hurdles:
Now a messaging system like the one described is a common feature. Sure there are few unknowns, but it is the sort of thing we ColdFusion developers do over and over again for various suites of applications. So I have a good idea of exactly what such a feature might cost. The problem is that even though I might be very sure of my numbers, when I tell the customer it will take 30 hours (just as an example - there are no real requirements here so please no comments!) he might go away scratching his head. "30 hours? For a simple form and an email?"
Why the disconnect? Largely it is because of perspective. A customer with no IT background simply does not have the points of reference to digest the whole enchilada. Additionally, Big Idea people often come from sales and marketing - folks who live for visual media. They might be the only people left in the world who still like Flash splash screens and banner ads. They are simply not wired to see the system as more than the items they can touch and handle. Moreover, it is difficult for them to grasp that working out the system and workflow and data interactions is more time consuming than creating the forms and templates. In fact, such customers may spend a dozen iterations tweaking the labels on the form, or asking for modifications in font sizes or styles. The same customer might never ask about speed, fault tolerance, scalability, extendibility etc.
Given the nature of how customers often see an application, it is important that we as developers work hard to expose the customer to the whole picture. This does not mean that the customer must be educated as to the nuances of DB indexing or why ORM is the way to go, or why jQuery is better choice than YUI. It also does not include high-handed, condescending technical jargon that is designed to awe and impress. It means that the customer needs to be exposed to some of the inner workings of developers. He or she doesn't need to fully grasp everything that is going on. But it is reassuring to be exposed to some of the complexity of the work.
When I was a younger man I enjoyed working on cars. I purchased a number of cars before I went to college. I would buy a fixer upper, make repairs and body work, get a cheap Earl Sheib paint job, and then resell it for (hopefully) a profit. These days when I open the hood of a car and poke around, but I don't really see a lot of things I recognize from working on my 1972 Oldsmobile 98 like the one pictured her - with its Rocket 350 V8 engine. Add some fading, a few dents, and a blue driver side door to this pic and you have the car I drove through all my years of college. Ahh... happy memories. I'm also old enough to not want to bother poking around under the hood of my car any more. So I tend to let the guys at the shop do all the work these days.
Still, when I go to the garage I do enjoy a full explanation. Maybe I just enjoy hobnobbing with folks who are not afraid of grease under their finger nails. One purpose of such chats is to reassure myself that the technician is competent as well as to understand as much as possible the work to be done. If a technician provides a thorough explanation I am more sanguine about the repairs, even if I don't fully understand it. On the other hand if he is condescending or impatient with his explanation, my confidence tends to diminish (indeed I might even become a problem customer).
The same phenomenon is at work in IT projects as well - perhaps even more so. In fact, I believe that one of the things that is poorly perceived across the board in IT projects is the importance of communication to stakeholders. I really think that developers and project managers put insufficient value on the task of making sure the customer feels good about the project. If you are one of the folks who just said to yourself "What?? What does it matter how he 'feels' about the project??" ... listen up. I'm talking to you.
You need the support of the stakeholders to succeed. Many projects fail because they lose steam largely due to discouragement on the part of customers. Project stakeholders need reassurance and they need confidence in you and your team. Finding ways to build confidence can mean the success or failure of the project. It is far from a mere "politicking" task. It is an essential part of communication with your customer. Some customers might pop the hood enough to say "Yep, that's quite an engine" and others might enquire as to the purpose of "that little thingy there" - but all of them need attentive, patient communication so that they are fully aware of the tasks at hand. This communication should exist whether the customer is Laissez-faire or not.
When estimating it is important to take the time to describe your tasks and requirements in a way the customer will understand - or at least sense. Descriptive requirements are important. Such requirements are not just written to satisfy the development team. They are also written (you might want to write this down) to provide substance to the tasks involved so that the customer can be reassured and informed as to the complexity of a project or feature. In other words, good requirements help justify the hours and cost. They are a customer relationship and sales tool as well as a development tool.
Every company or developer is different but here is what we do at CF Webtools. We have created a collaborative project system that we use to track all hours and tasks associated with a particular project. As developers have questions or finish items on the list they use this system to add notes to individual tasks. These notes are sent to the project team and to the customer in individual or digest form. Hours are tracked along with the tasks so the customer knows how much time is being used and can compare it with the estimate. The idea is not only to keep the customer involved in the process (which is an important aspect of creating acceptable deliverables), but also to demonstrate the pace and complexity of the work. It helps educate the customer about the scope of the work beyond just the visual aspects.
Of course some customers use the system effectively and appreciate the level of detail, and others rarely log in. But even those who do not log in see the notification emails and often respond via email (which is shuttled to the assigned team) with questions and comments of their own. In this way the customers see what is going on. It's not perfect and we are enhancing, revising and rethinking all the time - but it is working well for most of our customers.
Finally, I don't want to leave the topic of communication without taking the time to address the knowledge gap that runs in the other direction - between the customer and developer. Many developers do not take adequate time to understand the customer's business. When a new customer comes to you your first task is to understand the business they are in. It is not to figure out how many bleeding edge technologies you can pitch them because you like to shop in the toy store. Your new manufacturer probably doesn't need a SIM game, or a 3D flex visualization of ordering trends, or a social networking site for assembly line workers. As we use to say in Sunday School, "Stop, Look and Listen". Take an interest in the business. Be curious. Step out of your box in the same way you want him to step out of his. In the past year I have learned new things about:
I hope this post has brought out a few basic truths. Quality can be a more cost effective way to spend project money than quantity. Customers need your communication efforts even with very technical details. And you as a developer also have a box that deserves to be stepped out of on occasion. In our final post in this series we will discuss how to account for the "hidden costs" associated with estimating.