The management of projects and clients is the hardest part of running a consultancy. It’s also the part of the job that most are least familiar with. As a designer, Allan would much rather design and perform his skill set than manage a client. He especially hates talking to clients about money. A small miscommunication with the client can sour the relationship. It can also cost time and money and create project delays.
Development methodologies are suppose to help keep a project on track and also help avoid or predict pitfalls. There are several methodologies used by software developers. If you’re unfamiliar with them, perform a Google search for “Agile Development,” “Waterfall Software Planning” or “Scrum Development.” Read up quickly--then try your best to forget all about it.
Tons of web shops market themselves as “Agile Ruby on Rails shops” or “Scrum Development masters.” Marketing yourself using a development methodology is stupid because you’re selling a process to the client. You’re not selling yourself. You’re saying, “Hey, believe that this process will keep your project on budget and done right.” This is total horseshit. Selling a process makes you no different than your competition. What you’re really doing is assuring the client that, since you might not be that good, they don’t have to worry, because the development methodology will save their project. Sell yourself and make the client to believe in you. You’re the right person for this project. Show them why.
We use some Agile principles. Agile has quick development releases (which are likeable), but having to conform to a two week release isn’t right for every project. The best thing about Agile is its ability to break things down into week-long iterations and obtain early feedback from the client.
Scrum Development has a “scrum master,” which is a project manager of sorts. Each task is assigned points, and as tasks are completed, you’re able to see a “velocity” (how many points an average a developer can complete). Countless times, we have had clients tell us how some other development shop wanted to use Scrum and have Scrum training for the client, but they got overwhelmed. Scrum is nothing more than an accountability system. If you need to have an accountability system, you’ve hired the wrong people.
“Here’s what we do: we think that every project is different. We explain this to the client. All projects need small, one to two week iterations. After a few iterations, somewhere between two to three months of work, we should arrive at something launchable.”
This is a good point to stop, take a breath and evaluate the completed work. The client may not want to launch, and that’s fine, but if the client hasn’t launched after six to nine months, you’re going to have a problem. It means that the client is nervous and it’s probably time for them to find a different team.
In an attempt to maximize profits (or out of ignorance) many companies will hire junior-level people specifically to write code. They’ll then have a senior-level person act exclusively as the architect for the project. They’re sure that if they have enough process in place it will ensure project success. This is a fallacy. This is insanity. Process is good, but it is irrelevant with bad people. Good people will do good work regardless of process. In fact, the better they are the less process they need, because they’ll probably already have their own process, which has worked for them many times before. Do not make the mistake of going with one process or another just because. . . Find what works best for your team and do that. Adapt and change when new people are brought on board. Hire good people and trust them to do their job.
Every second you spend managing a project it costs your client money. Make them aware that the more proactive they are in the project, the more it’s going to cost them. Duh, time is money. Every email they send you, and every phone call they make is costing them money.
To be clear, a web prototype is a static website that has a few actions to make it look and seem “real,” but there aren’t any databases or a dynamic logic anywhere in the project. Its purpose is to give the client and development team something to click around in and make interface decisions with. It’s much easier to make the interface decisions early in the project before developers get involved and you’re required to move large pieces of code around.
Most clients won’t want to prototype their app. Even if all of the code in the prototype is reusable, they’ll want to just build it anyway in order to finish faster. We’ve only done prototypes when the client needed to arrange funding or buy-in from the check-writers.
You must build your own projects, because your clients will ruin it, with their ideas, if they get too involved. Potential clients sometimes ask you to show them some former client work. This is where it helps to have your own products. Tell them to look at your own work and apps. How can you judge a consultancy based on past client work? You don’t know how much of the project they were involved in. Perhaps the client had terrible requirements. You can’t see through that stuff and into how the consultancy would make decisions.
“If you want to see how we make decisions--how we build and implement things, just look at our apps.”
A consultancy without any of its own projects is a real head-scratcher. How is a client supposed to trust you to make decisions with their project (using their money), when your consultancy doesn’t even build its own apps? Clients are looking to you for answers, and if you don’t have the self- confidence to build your own apps, then how are they supposed to trust you? Would you trust a golf coach who hasn’t swung a club before? Would you trust a chef who hasn’t tried his own cuisine?
You might consider bringing up the fact that most consultancies don’t have their own products, therefore they don’t know how difficult it is to run a SAS business or deal with the problems they’ll face.
It’s not as painful as it sounds. Writing a proposal won’t really make you money, but if it’s written properly, it will save you money, time, frustration, and everything else that’s horrible about your industry.
“We get requests for phone calls and project quotes almost every day. Most of our projects have a good level of complexity. We don’t have any sales people on staff, so it is our job to handle clients as well as design and build the projects. A functional proposal can take many hours to write, and we cannot afford to waste those hours every day writing proposals.”
The following is a detailed outline of the LessEverything system. Before signing a non-disclosure agreement, Allan and Steve speak with the client briefly about their project in order to get a general idea. No NDAs are signed until it is proven that the client has a reasonable budget. In this conversation, no real details are discussed. It’s a quick, 10-minute conversation about their project. Then, a very quick proposal is written and put with a price range. Google Docs is used for writing these proposals. Any word processor will work, but it’s better to use something online that makes it easy to collaborate.
A lot of people write their proposals as a story. Stories are not quick to read or write. Use lists. Remember: not only does your client need to be able to see their vision in your proposal, your programmer also needs to understand the business logic for the project.
This is the idea of a quick proposal. Using lists frees the writer from grammar or structure, so a first-round proposal can be thrown down fairly quickly. Put a price range on this (for example: $15k-$30k). There will be questions you need to ask before you can tighten down your project/time bid.
At this point, show the prospective client the first-round proposal. He or she might be scared by the price and leave. This isn’t a bad thing, because you haven’t wasted much of your time. If they agree that the price range is within budget, have another conversation delving deeper into the project. In many cases, the client will tell you upfront what their budget is. This is great. It will allow you to do your best to keep the proposal within their budget so you don’t spend hours writing functionality they can’t afford.
After more conversation, you’ll gain an even more specific understanding of the client’s needs and be able to fill in the gaps of their proposal. Your proposal should eliminate confusion, so if there is functionality that isn’t listed but needs to be done, be sure to list that as well. Make it as detailed as necessary to avoid confusion, but also make sure it is as short as possible.
Getting started on a project requires some planning as well, so be prepared to create an outline of steps to get your project off the ground. Here’s a sample of the stages of a project as a guide:
After the final payment has been received, you need to focus on maintaining the new relationship with your client. Follow up to make sure they have everything they need and are satisfied with the deliverables. Make sure they have a direct line of communication with you so you are able to answer their questions quickly.
Satisfied clients are going to help your business flourish, so it’s important to make sure they’re ready to rave about your work and excited about their project. Take the time to follow up with them weeks and months after project delivery, so that they know you’re available to take on any other projects they might need. Always keep in mind: You need to do what’s best for the client--not what’s best for you. Make it a point to keep your client’s best interest in mind so that you are delivering a high-quality product.
People are always asking LessEverything to sign NDAs. Allan and Steve sign most of them, because it has become a necessary step in opening the discussion about someone’s idea.
“I can’t tell you how many times we’ve signed an NDA and the idea winds up being, ‘I want to build a website that is just like this other one--except with better navigation.’ We have a bunch of NDAs in our filing cabinet just like this, and they are worthless. This is because an NDA only covers things that are not already publicly known. If an idea is 97% stuff that is already out there, that NDA is only going to cover the 3% that’s new.”
In 2010, LessEverything changed from fixed bid to hourly. They changed because the painful documentation-writing process was too time- consuming, and they already had two medium-sized projects on deck. These were good people, and Allan and Steve kept going from liking them to not liking them and back again. This soured the trust in the relationship a bit and the situation generally sucked ass.
Once a client decides that they want to work with LessEverything, a contract is signed and work is started on the project features and timeline. A bill is sent for the first two weeks of work and once payment is received, they move to the next step.
LessTimeSpent.com is used to invite the client to a given project so they can, at any time, pull a report of the hours worked. It’s the client’s responsibility to make sure the project is not going over their budget.
The first phase of the project is planned out in LessProjects.com (LessEverything’s project task manager application). Here, the first two to four weeks of builds are listed out. The time length depends on the project size and client budget. It’s easy to charge for this time as the first part of the project.
This is where the work starts. Every person on the LessEverything team is a senior level developer, so it doesn’t really matter whether design or code is done first or at the same time. Allan’s HTML is always very simple: Table layouts for everything. No, just kidding. Tables for tabular data, ULs for lists, Divs for the rest. Allan is able to create partials and move code around, so there’s no problem there. He rarely even breaks JavaScript anymore.
At the end of week one, LessEverything sends an invoice for weeks three and four and keeps working. The company is always paid in advance. Always. Always. You should be, too. You are not a credit union. Net 30 is the stupidest thing in the world.
Once launched, work on the project is usually stopped and allowed to simmer. This is the time for the client to figure out if they have a good idea or not and for them to collect feedback from their customers and decide future direction.
Rinse and repeat.
Cashflow is the lifeblood of your business, here's how to avoid cashflow issues.