Composr Supplementary: Guide to running a web agency

Tongue-in-cheek guide to starting a creative agency (copyright Ben Horsley)

(Click to enlarge)

The Composr community welcomes other companies to provide professional services based around Composr CMS. To that end this tutorial has been created to provide an outline of how to set up and run an agency, based on the experiences I've had building up my former company, ocProducts Ltd.

I aim to provide you enough information to learn the important skeleton of running a stable development business – so that you can then work to flesh out things in your own particular way, appropriate to how you want to run your own business.

The processes are a bit biased towards fixed-quote projects rather than projects with an agile budget. However this is a good thing because agile projects are the simpler case – there is much less risk, need for upfront planning, and costings work – because things are done in smaller independent iterations with an ongoing commitment to keeping the project (and budget) going.

Staff roles

Generally-speaking, a development company will need people filling the following roles:

• General management (including: hiring, performance reviews, strategy, building partnerships, etc)
• Accounts (including: regular state filings, formal accounts, corporation tax returns, payroll tax returns, sales tax/VAT returns, and regular payroll)
• Project management (including: account management, relationship management, client meetings, and assorted jobs like SEO and writing documentation)
• Design (including: graphics design, copywriting, information architecture, interaction design, basic HTML and CSS, user experience testing)
• Programming (including: server-side programming, client-side programming, server maintenance, and tech support)
• Marketing (including: new business sales, getting repeat business, getting referrals, branding, PR, market analysis, competitor tracking)

Don't neglect any of the above tasks, they are all critically important. For example, sales don't happen magically on their own just because your company exists and has good skills.

The larger the agency, the more the jobs roles can be split up, the larger the hierarchy will be, and the more likely other roles will come into play (secretary, etc).

Software

You will need to decide what software you are going to use internally. Standardising is important so that people are working consistently and efficiently. You'll also need to budget as not all software is available in a good FOSS form.

Here are some areas to consider, and suggestions:

• Internal chat (e.g. Skype, HipChat, IRC)
• Sharing files (e.g. Dropbox)
• Writing documents (e.g. Microsoft Office, LibreOffice, Zoho Docs, Google Docs) – sadly, no Open Source tool can currently match Microsoft Office in terms of stability, ease of use, and performance
• Source code control system (e.g. Git, Bitbucket)
• Issue tracker (e.g. MantisBT, GitLab issues, JIRA)
• Standard IDE (e.g. CodeLobster, Netbeans, PhpStorm, TextMate)
• Analytics (e.g. Google Analytics)
• Stack software (e.g. LAMP)
• Framework software (e.g. Composr CMS for advanced sites, Wordpress for blogs, Magento for eCommerce, Symphony for business process implementations)
• E-mail provider (e.g. Zoho Mail, or running your own internal e-mail); possible "all staff" mailing list; standardised e-mail signatures
• Calendar provider (e.g. Zoho Calendar)
• Up-time monitoring service (e.g. Uptime Robot)
• Anti-virus system (e.g. AVG)
• Browser testing (e.g. BrowserStack)
• Online signatures (e.g. Echosign)
• CRM (e.g. vTiger)
• Annotating PDFs (available in the standard Preview app on a Mac)
• Recording screencasts (e.g. TechSmith Capture for quick and dirty screencasts, ScreenFlow for Mac, Camtasia for Windows)
• Diagramming (e.g. LibreOffice, Balsamiq, ArgoUML)
• E-mail client (e.g. Thunderbird)
• Graphics (e.g. Photoshop, GIMP) – sadly, no Open Source tool can come close to Photoshop or have good support for psd files which are very much a standard
• Database management (e.g. HeidiSQL)
• FTP Client (e.g. Yummy FTP for Mac, FileZilla for Windows)

Infrastructure

Here is some infrastructure you will likely need:

• Office space with power, heating, mail, insurance, parking space, security, etc (e.g. a serviced office)
• Standardised desktop environment: hardware (e.g. large screen sizes, SSDs, ergonomics)
• Standardised desktop environment: software (e.g. Windows for managers, Mac for designers, Linux or Mac for developers)
• Internet connectivity (e.g. cable)
• Phone connectivity (e.g. VOIP with handsets or headsets)
• Internal servers (if any, probably not necessary nowadays)
• External servers (e.g. staging server)
• Hosting environment (e.g. dedicated server with multiple sites, VPNs via Amazon EC2, separate shared hosting accounts)
• Social media accounts (e.g. Twitter Profile, Facebook Page, YouTube Channel) [see the Supplementary web technologies (media, social networking, etc) tutorial]
• Your own website (duh!)

For your infrastructure you will need:

• Ongoing security management
  • how client sites on a shared server are separated/firewalled (e.g. exact documented security architecture used)
  • monitoring of security vulnerabilities for all stack/framework/CMS software used
  • patching/upgrade process
  • possible intrusion detection systems for hosting (e.g. a custom one)
• Backup process

You will also need to take out various different kinds of insurance policy.

Internal processes and documents

To run a professional organisation you will need to define a large number of processes to be followed by your staff, this section has some ones that may be important.

For a few I have created further sections in this tutorial, but mostly I haven't gone into any further detail. You'll find examples and discussion online for all of this. The actual final documents you create will need to be tailored to your particular business.

Hiring:

• Staff induction process (e.g. training, setting up of accounts, introductions, distribution of guides, setting up insurance and payroll, etc)
• Interview process (including your own standardised testing that interviewees can't cheat against)

Projects:

• Overall project checklist
• Quote process
• Client communication process (e.g. when should a developer be able to directly correspond with a client)
• Developer/designer briefing process
• Development process (e.g. what particular agile process)
• Job-specific standards and processes (e.g. coding standards)
• Work reviews and sign offs
• Job-specific checklists
• Formal testing process(es) (e.g. unit tests, code review, and design meetings)
• Server/hosting-access process
• Support process

Internal general staff management:

• Hierarchy, e.g. who line managers are, who is senior, who reports to who
• Overtime policy
• Feedback/suggestions process
• Complaints process
• Training process
• Safety training
• Dress code
• Holiday procedure: making requests, tracking holiday days, and out-of-office messages
• Staff discipline procedure
• Reporting process (e.g. team meetings, end-of-day status reports, time-sheets)
• Staff progress/performance review procedure (possibly with a metrics component)
• Company values document
• Developer/designer scheduling process

Miscellaneous:

• Open Source contribution process (when staff may spend time contributing, and how to contribute up-stream changes)
• How priorities are decided on (e.g. dependency management, priority levels, acceptable levels of technical debt, testability, compatibility management, how to support code long-term that is for a niche-audience only, cycles/lock-downs)
• Security processes, e.g. how to deal with private client data, and how to securely hold (e.g. a password manager) and send client passwords (e.g. temporary passwords just for the customer)
• Server management process, e.g. who has access and what they are allowed to change

To give to clients:

• Stock responses to particular query types (if you get lots of customers asking the same thing and the answer isn't quick to give)
• Rate card (how much you charge per hour for different skill types, and whether that is a true hourly-rate or used for calculating fixed-price quotes)
• Government-clients may require particular documents for legislative reasons:
  • Environmental policy
  • Equal-opportunities policy
  • Quality policy
  • Operational disruption policy
• Standardised company and product information document
• Standardised conditions of business
• Feedback forms (to give after project completion)

How to talk to customers:

• Politeness
• Good spelling and grammar
• Friendliness
• Professionalism
• When to debate vs when to take a "customer is always right" attitude

Of course you need to find a sensible balance between common sense, and making sure consistent standards are upheld. So don't go overboard with things and aim to hire staff that have strong professionalism and common sense!

Winning work via proposals

Very commonly new work will be won via a proposal process, i.e. the reviewing and (hopeful) acceptance of your written proposals.

I should note that this is not always the case: sometimes clients prefer in-person pitches, and some will simply pick the first supplier they find/like/know.

To write good proposals effectively you will want to have stock text available to start from. You will lose out on most competitive proposals for reasons entirely out of your control, so you can't usually spend more than a couple of days writing them. Even when working efficiently, a big proportion of your business costs will be in writing proposals (unless you secure significant repeat business from your clients, which may be the case if they expect to be making ongoing investments, rather than having large gaps of time between work).

Stock text should usually cover:

• About your company, including basic details like your contact details and location
• About your key staff
• About your principles, approach, and USP; what is a good website to you?
• How you are keeping up-to-date with industry changes and providing cutting-edge solutions
• How you approach challenges such as security, mobile, and user experience
• Your project management process (including phases, and sign-offs)
• Examples of recent/relevant successful past projects
• Benefits of your chosen software (e.g. for Composr CMS: avoiding dependencies on third-party systems, better integration, better user experience)
• References to best practices/standards/accessibility/quality processes.
• Standard supported browsers (e.g. latest Chrome, latest Firefox, latest Safari, IE10+, iPhone 5+, Android ICS+)
• Proposed hosting solution
• Maintenance agreement (e.g. for upgrades, and long-term bug fixing)
• Training process
• Support process

Look at other company's proposals to get ideas for the kind of text that is needed (you'll be able to find some). The bar is often set very high, as companies tune their proposal text over years.

Add a copyright notice to the footer of proposals. This is so a client doesn't get someone else to implement your proposal.

As well as stock text, a proposal must (primarily) be speaking directly to the specific project:

• How you intend to approach that particular project
• Demonstration of great insight
• Show passion
• Some form of task break-down, with implementation time
• Some amount of design work (see the "Design" section below for documents that could be delivered within the proposal)
• Particular staff expected to work on the project (potentially – this may sometimes be feasible, and sometimes not)
• Phase break-down and payment schedule
• Demonstrate good value and competitiveness

Try and get the correct balance between detail and succinctness. The correct balance depends on what a particular client appreciates – so everything must be reviewed and tuned for the particular client you are writing a proposal for.

Generally it is better to focus on quality rather than price. If a client is shopping based on price they probably will end up picking the vendor that gives a 30 minute phone call (and low quote) rather than the vendor spending 2 days writing a detailed proposal. You want to avoid low-grade work as it is impossible to break even on it when employing skilled staff.

Deciding on payment schedules

For new clients that you can't really trust (e.g. new businesses where the owners seem rather non-committal, unengaged, or non-positive), you may want to insist on something like 40% upfront payment. For other large projects payment might be done in 4 phases (as per the example). For maintenance projects you may usually just invoice for payment after delivery.

Payment schedules can be based on the progress through the original production schedule. If clients therefore stretch the production schedule somehow, it won't affect payments. Payments schedules should not be very drawn out as ultimately you as an employer have ongoing salary to meet.

A specific example

The standard ocProducts payment schedule was the following:

• 25% upfront (if they are a small business and won't agree to this then warning bells about them should be really firing)
• 25% when design agreed on
• 25% when deployed for acceptance testing (i.e. primary development completed)
• 25% one month after the previous 25% (which is when our bug fixing commitment also expires)

Contracts

There is little agreement on whether contracts should be drawn up. Generally things work via either:

1. Detailed contracts written up by a lawyer
2. Simple contracts based on a "modal" contract
3. Simple contracts written up internally
4. Standardised "conditions of business" documents that must be signed
5. An understanding based on an ongoing relationship
6. Completely ignoring the issue

Frankly most companies go for '6' because they either don't want to spend the time or think that a contract is worthless without a good understanding, and with a good understanding you don't need a contract. My company operates via '4' because there are always situations that might come up that parties may not agree on (or forgot-that/misunderstood-what they agreed on) unless put down properly in writing.

There is a lot to be covered in a contract. The most difficult thing is how unexpected work should be dealt with. Many clients may naïvely think they may request new things or changes without it changing the cost or schedule, so a contract usually will detail how exactly this is handled. There are also issues relating to process, responsibilities, what happens if particular responsibilities aren't met, how bugs are handled (liabilities), and intellectual property assignment.

It is best that you look at a number of different modal contracts to construct your own – or, get a lawyer to do this.

Company values documents

It is good to have a values documents so that new staff hires know what you want your company culture to be.

Culture is a tricky thing:

• On one hand you really don't want to create a monoculture, and you shouldn't use the phrase "cultural fit" as a synonym for "is a slave to work" – but you also should have some general shared principles that define the approach within and without your company.
• The difference between "culture" and "skills" isn't clear. But it doesn't really need to be in a values document.

Sample (what we told new developer hires to the former company ocProducts)

You'll be on client projects using Composr, which often results in improvements being fed back into the next version of Composr. It's a rare opportunity to contribute to an Open Source project that influences huge numbers of normal people.

As a developer you will likely find these as your biggest challenges:

• you need to become great at working in large complex code bases (being able to quickly understand code you didn't write, and navigate and jump around large codebases efficiently as you work)
• you need to teach yourself to automatically meet a lot of different standards in the code you write (internalise your understanding of them to the point where you don't need to think about it).
• you need to implement things into Composr without breaking upgrade compatibility or "reinventing the wheel". Composr is great at this kind of thing, but it takes some getting-used-to. In other words, you need to work within our framework in order to leverage the advantages of our framework – it's hard but gives real benefits and a better end result.

Our values:

• Don't be shy. Please ask questions relating to Composr development if you get stuck for more than a few minutes. We would rather spend a minute answering your questions than you spending a hour answering them yourself – it saves us money!
• Openness and Honesty. We are an Open Source company, and are as honest and open with our users as possible. Of course we can't just blurt out things like internal release dates as that can cause misunderstandings, but such things are the exception to the rule. We respect our users and try our best to relate to them.
• Engagement. It's better to work with people than to shut them out. If there's a problem, it's probably true that other people have the same problem – so we would seek opportunities to engage with people to fix it.
• Learning. We're all learning, and are at different points in the learning process. Chris wrote Composr, has done work for banks, and some of the world's biggest companies – but he was a bad programmer when he started 25 years ago. We should respect that not everybody is at the same level and help each other. This is done through feedback and criticism – we have to tell each other when we have some learning to do.
• Intelligence and initiative. You have to be very smart to work with us, but we're sure you are! It's important to be able to make sensible decisions on your own. If you get stuck on something, it's important to have the project/time management skills to be able to move on to something else until somebody is free to help out. Our clients need us to work efficiently, so we all need to try and do this, but also not rush and cause quality issues or stress (sometimes clients will expect too much – we'd rather get rid of those clients, than damage our reputation and personal effectiveness by doing bad pressured work).
• Standards. We try to do things properly wherever possible, and to a high quality. For example, we care about accessibility of our websites, so we made Composr support ARIA and WCAG and other accessibility standards. Of course, manually checking against a lot of standards would really slow our work, so we try and write tools for this or have a broad enough understanding that we know how to do things right without needing to think hard about it. There are many different areas where quality has to be kept high, for example – code maintainability, design quality, correct use of grammar, and standards-compliance.
• Quality in general is extremely important (for example, if we make a website, we try and make it as good as top websites like Amazon).
• Feedback. We're also open to genuine feedback on Composr itself that you might have, very small things, or bigger things. We're very proud of it but there's always room for improvement. If you notice something like us not explaining things well in the Code Book, a broken link on our website, or an unneeded performance bottleneck, post it on the tracker!
• Innovation. We're always trying to innovate in Composr, to make things better for people in ways other software does not. For example, our Theme Wizard.
• Ethics. It goes without saying really, but we try to be very ethical.
• Humour. Did you know CSS stands for 'CurSeS', that the boss of Microsoft is insane, and that we named our company after the evil company OCP (from Robocop)?

Server/hosting-access process

Here is a sample process for deploying files to a server individually (using Git to deploy is a more modern process, but would have similar steps):

1. Never access hosting without getting permission first.
2. Never access hosting outside office hours unless given specific permission.
3. Never access hosting unless a senior member of staff is available through IM, unless given specific permission.
4. When overwriting files always take a backup of what was there already.
5. Keep an archive of the hosting log for each upload.
6. If it is possible that the files in Git are much newer than what is on the site, and can't be uploaded yet:
   1. Download files that are going to be overwritten, into a minimal duplicated directory tree that mirrors the live server
   2. Run a diff tool (like Kompare) between that directory and the Git directory
   3. For each file, you can decide whether:
      1. It is new, so can be uploaded immediately
      2. The only changes are changes you're trying to deploy, so can be uploaded immediately
      3. There are a mix of desired and undesired changes. In which case, use the diff tool to apply the changes to the copy downloaded from the server, then upload that copy

Upgrading live sites

This scenario adds additional complexity, as revisions to the live code can introduce unexpected bugs that may not have been eradicated during testing.

For anything that cannot be checked through normal click & type style testing, a risk analysis should be performed to predict where system failures may potentially occur.

For example:

• risk of e-mails going to the wrong people, or having incorrect information
• risk of e-mails going out too often
• risk of live upgrade not being easy
• risk of incorrect payments being made: too many, or too few
• risk of someone having access they've paid for being removed
• risk of someone's details being leaked
• risk of losing or corrupting data
• risk of roll-back to a previous version without having any data loss being too hard

A report should be written up by the developer, stating how each risk can be mitigated, which should be reviewed by the project manager and a senior developer. Once reviewed, the report should also be sent to the client.

For example:

• to mitigate against the risk of incorrect e-mails or transactions happening, the developers could plan to queue them for review before sending them out. Once things have proven working correctly in-the-wild the queue can be disabled.
• to mitigate against the risk of a difficult live upgrade, make an upgrade script and repeatedly test it on a copy of the live site until it works 100% – nothing at all should need doing for an upgrade to work except running the script.
• to mitigate against the risk of incorrect payments or someone losing access, pick out one user from each scenario in the system and test in advance (using a live DB copy) that the upgrade handles their cases correctly.

In areas where serious risks are identified, significant extra testing must be done, with an audit trail of test results.
These steps should all be completed before costings are made, with the results then factored into the costings. This should include the time taken writing/reviewing the report and the extra testing.

Overall project checklist

Here is a sample checklist for managing an overall project:
 ✓ Project is added to CRM
 ✓ Strong client relationship established
 ✓ Confirm the client agreeing to things and the name on the invoice are one and the same, and we know their name and address
 ✓ Client deeply quizzed on their requirements, understood intimately – "hidden" requirements identified
 ✓ Proposal written
 ✓ Assured that our proposal is in line with the client's business model for success
 ✓ Client briefed on our terms and conditions
 ✓ Tried to catch client out on them forgetting to tell things and then explain their need for contingency directly within their own projects context
 ✓ Up-selling of possible additional services
 ✓ Price agreed, in writing (based on real developer discussions and multiplier)
 ✓ Price not agreed against any outstanding designs the client may be making
 ✓ VAT situation agreed, in writing
 ✓ Scope agreed, in writing and client agrees proposal is inclusive of all requirements
 ✓ Deadline agreed, in writing, with multiplier
 ✓ Terms and conditions signed on Echosign; or, contract
 ✓ Work all covered by Bitbucket issues
 ✓ Deposit invoiced/paid
 ✓ Calendar events for key dates
 ✓ All project details in Dropbox not personal e-mail (e.g. passwords)
 ✓ Design under way, using an existing unused stock one as a base if possible
 ✓ Design meets our quality standards
 ✓ Design done and developer says is buildable
 ✓ Design finalised with client, “sign off”
 ✓ Design invoiced/paid (if applicable)
 ✓ Developer properly briefed and booked in
 ✓ Work getting done in Git
 ✓ Work regularly updated to staging server, if appropriate
 ✓ Change management process used correctly: changes must mean scheduled changes. Any freebies or infractions should be recorded in a spreadsheet
 ✓ Developer progress to schedule
 ✓ Development checklist completed
 ✓ Risk assessment done, if appropriate
 ✓ Deployment plan done and checked by senior developer, if appropriate
 ✓ Work thoroughly checked, ad hoc ; also, peer developer review if appropriate
 ✓ Work thoroughly checked, formal test set
 ✓ Final work demoed
 ✓ Final work deployed to deployment plan
 ✓ Deployment invoiced/paid
 ✓ Testimonial gathered
 ✓ Any maintenance or security agreements or training is scheduled/documented
 ✓ 30-day invoiced/paid (or as applicable)

On costings

Our Project pricing, Choosing a software company for your project, Minimum Viable Products, and How to approach complex projects tutorials try to do a good job of explaining the true cost of building very high quality websites. These are extremely useful resources to send to clients who are new to client-side web project management.

In most cases ambitious customers will have in mind sites that are comparable to their favourite sites, i.e. some of the best in the world. Composr CMS attracts very ambitious customers due to its high power and relatively lower implementation cost. Relatively is the key word: maybe 60% of the cost, rather than 5% of the cost.

To this end it is important to bear in mind that many customers (the majority, honestly) simply will not be able to afford what they want. Frankly if you want to run a successful development business you need to be able to quickly identify these situations before you invest a lot of time in a project, to avoid wasting your time and the customer's money, on something that may be not possible within the budget available. You'll either need to avoid these projects, or make a good proposal for a minimum viable product that can be grown via ongoing investment.

Modern web users expect very high quality websites, on par with the production values of TV or print. Entrepreneurs expect to build what their customers expect to see. Very high quality websites can be cheaper, but never cheap. It's a hard reality to accept and something people get very emotional/hostile about, as the web has evolved very quickly from a bedroom coding situation to a situation where huge teams work on things – but it is the reality of the modern web.

Account management

Here are some guidelines on being an excellent account/project manager:

• "Get into the client's shoes" when considering their needs.
• Impress the client by showing that you really understand them.
• Impress the client by showing you really know your stuff.
• Try and make sure you have a good understanding with the client on what is needed. Address specifics, resolve ambiguities, ask questions. Try and put your self "in the client's shoes" and identify other things they might want, like data imports, searching, need to edit default structures, administration screens, etc. Once you get past brief/proposal stage, the client will need to pay extra for anything not documented, so it's important to be clear on it in advance and get sign-off.
• Where applicable, do risk estimates (e.g. if there is eCommerce, encrypted data, fragile integrations, complex dependencies, firewall issues, or privacy issues). Consider how much time will be needed to properly manage the risks (such as logging, extra testing, redundancy, extra error checking), and consider legals to cover yourself.
• If you are being asked to respond to a PQQ, ask if you can have a direct conversation with them.
• Also try and see things always from the client's perspective, if there are any conflicts or annoyances. Remember that you are the expert at project management, not them, so it is up to you to explain to them how they need to operate if they are doing it wrong.
• Empathise with the client. If they've taken a lot of time to explain amends, thank them and say it must have taken a while. Build a relationship of mutual appreciation.
• Set expectations: explain what will be happening to a client, and try and understand their unstated needs and biases. If there is a potential for an issue (e.g. a design-focused client seeing interfaces written by a programmer), explain in advance the process and order of things. If prices will change, say in advance. Make sure the client-agency relationship is well-defined, so clients don't expect something you might not be able to offer in the future. Never imply that you can meet a time estimate before going through the formal process of making a proposal or estimate to them; unless you make it absolutely clear that it's an early estimate and for a very rough guide only. Don't over-promise in haste just because something seems easy – always say you'll get back to a client on something if it isn't something 100% known.
• Act professionally.
• Always be nice, except when you can't be.
• Don't be afraid to discuss with the client if they are clearly wrong about something or their ideas can be improved on.
• …but ultimately (after discussions) the client is always considered 'right', except when you have a contract to uphold.
• Keep in regular contact with progress updates.
• Reply to e-mails promptly, even if to say that things have been scheduled in (i.e. deferring real reply).
• Set out-of-office e-mails when you finish for the day, so client's know you can't reply quickly (often clients are in different timezones, or have weird expectations of you working 24x7).
• Watch what you get yourself into. Don't for example agree to let a client host temporarily on our server just because you can, because then they'll expect migration work, backups, synchronisation, support for any technical problems on the server, ongoing service if the server configuration changes. It could create load problems, security erosion, etc. It is very easy to let a small thing turn into a big thing if you're not constantly vigilant.
• Use a company calendar to manage appointments and scheduled work. Generally double the expected time should be allocated in case of overruns or unexpected new work or changes to be fitted in.
• Keep a todo list for yourself.
• Where appropriate (i.e. on a tight schedule) notify a client of any public holidays that may occur during the development process.
• Generally you should never give discounts, as it sets a bad precedent, and anything free tends to become a platform for the client wanting more free. However, if you have made some kind of mistake or if it's a very large job and you are struggling with a small remaining amount of budget then you will sometimes give the client a discount on something. If you do this then it must be formally documented in a document you send to the client when the project is nearing completion (e.g. with their deployment invoice). Always be willing to walk away during a negotiation, never get too emotionally or procedurally invested until you're happy with the financial and management framework for it (i.e. that you won't be messed about with, and that the client can afford what they'll truly need).
• If a client asks for a quote on something very complex, or asks complex advice, you will need to research it. In this event you may need to charge for the research time regardless of whether they accept the final quote or not – explain this to the client and quote them on what that research time will be. Rule of thumb: if it takes more than an hour to work out, it's research; don't rush things just to get them free, it'll only create problems if you don't research things properly.

Design

The design management process might be roughly as follows (written to the perspective of the project manager):

1. For complex sites make and show to client formal diagrams where appropriate – Gantt charts, copy documents (usually the client will do these), wireframes (usually only for new functionality Composr cannot already do), UML class diagrams for database tables, data dictionaries (when interoperability is needed), site maps (good for new-media-style websites) and/or UML use case diagrams (good for very large complex dynamic sites) and/or XP stories (good for weird sites). Make sure no new hidden requirements are accidentally created.
2. If the client wants creative input before designs are made act appropriately to gather it and involve them (the should have been established on their brief, or in meetings, and written into the proposal as part of the process).
3. If a client is creating the designs be careful to discuss and cover off any "implied" functionality which may not have been mentioned before. Really this kind of thing should be done before agreeing the quote, as things can get very out of hand.
4. If creative design work is required, book in the designer to create the designs: the global design, and key screens.
5. The project manager and designer must discuss issues relating to appropriateness to brand, uniqueness, general attractiveness (e.g. 'bling', sensible use of palette, consistency), use of space, visual hierarchy, accessibility, usability, information architecture, interaction design. There will be lots of back-and-forth till it's 'fully resolved'. Generally it must be really really good, to a very high professional standard. Make sure no new hidden requirements are accidentally created.
6. The developer must agree designs are buildable – ensure they do and if they can't feed it back to the designer.
7. If creative design work is required, get the clients agreement on the designs. This may require quite a lot of back and forth, and in higher budget cases, a meeting. The client must clearly say in an e-mail that they are happy with the designs and that no further design amends will be needed, and that it is time to proceed to the development phase. If the designs won't end up being used, store them in a standard place (maybe you will re-use it for a different project, or a Composr theme)

Development

The development management process might be roughly as follows (written to the perspective of the project manager):

1. Commence and manage development, to schedule. The programmers should already be aware of the tasks as the project manager has already put them on the issue tracker and got developer time estimates.
2. The project manager needs to monitor developer process 2-3 times per week to ensure that they're work is going to schedule. Developers should be sending daily e-mail reports if not in the office, marking things as done on the issue tracker, and giving either screenshots or instructions on how you to check their work. Never lose a handle on how well the schedule is being met and the quality of the work currently completed. Never trust a programmer is following process or done when they say unless they have developed a good reputation for that: a project manager should challenge them to prove it.
3. Keep the client updated on the development process as it goes, and continue to react to client feedback / changes. If the client has requested an agile process then give them access to view the staging server.
4. If scope or process changes happen, tell the client. Using the change management process, decide whether the changes are free (in which case say they will be recorded on the restricted list of freebies the client has received), or to be charged for (in which case, agree on the cost – or don't do them). State that any freebies given out does not apply amends to them or further scope extensions will not be charged for. This is essential, if minor scope creep goes unmentioned it can creep further and it is hard to retroactively say "this is not in the spec" if it's already implicitly committed to yet has nothing to reference against. Charged amends are also very likely to affect schedule, and code integration points (i.e. the ability for work to come together for integration checking), so make sure this is communicated.

The post-development process might be roughly as follows:

1. Make sure the developer produces and has passed a functional test set. Go through it and make sure it all works and that the test set is comprehensive, and give the results of this to the client – or show them the unit tests that have passed. There likely will be some back-and-forth until the client can be allowed to see anything (but you should be far ahead of schedule at this point).
2. For non-maintenance projects or maintenance projects that require some review, give a link to the staging server to the client.
3. Feed amends as required, remembering you have a proper change management process for this. If the developer is not in-house then feed them through to the issue tracker so that they can be tracked (not e-mail or IM unless they are really trivial issues that will be fixed immediately). For efficiency you could just attach client bug reports en-masse into single issue tracker issues, there is no need to re-flow everything into single issues. Do not bring perfectionism to issue fielding, only clarity. Be fast and furious with the reporting pipeline, because there will be 100s of issues, and they mostly just need fixing not deliberating on (which would suck up endless days in discussions).
4. Redeploy to staging server (repeating steps 2-4 until done).
5. For new projects, set up an up-time monitor
6. Review project success, comparing expected times and actual times. Learn any lessons that need to be learnt and feed back to improve processes if required.
7. For new clients, send them a feedback form. If you get good feedback from this then ask them for referrals (i.e. names of other businesses they may know).

Of course through these processes you'll be invoicing and checking/chasing payments too.

Making quotes

If you work with fixed quotes (rather than an agile charging structure), then you will of course need to work out what quotes to give!

When making a formal quote, you might roughly double the time you think each part of the project will take i.e. (designer time + developer time) × 2. Then work out against your standard rate. The doubling is just simply due to the fact things always take longer than expected; the actual multiplier you use should be tuned based on experience to be as realistic as possible.

Remember also this rule of thumb: "If something bad can happen, it will.". Typically any extra cost you can think of will happen. Any promise you make should have a serious consideration in the quote to ensure you can meet the promise.

Consult with the developer(s) to make sure they think they can meet the time estimates. Don't make up estimates on behalf of other people!

When working out hourly rates consider all your costs. For example, consider that new developers take a lot of time to learn.

Never forget to add on time for non-developer tasks. For example, project management time. Typically a project will have roughly equal design time, development time, project management time, and marketing time. The marketing time may well be the client's own time, and hence not charged.

Special cases

Be aware that on projects there may be special cases that you need to be extremely careful about.

If there are multiple companies involved

Multiple companies on a project can lead to significant complexity increase in project management. Make sure a proposal for such a project clearly specifies:

1. The chain of communication for project management (e.g. if multiple chains of communication exist, this will incur additional project management costs).
2. The chain of communication for giving cost estimates – included requirements imposed on your company.
3. The chain of responsibility (e.g. if an intermediary is paying, they have a responsibility to pay regardless of whether their client pays).
4. That if an intermediary company will need additional training and support, this must be paid for. Ongoing free consultation should not be implied.
5. That any intermediary company should make sure their client sticks to your conditions of business, as you will need all parties held to them.
6. That any intermediary company puts in place a contingency budget and/or an effective process for getting funding for additional work.

Multiple stakeholders

If there are multiple stakeholders it may be a good idea to try and build a relationship with each stakeholder to get them on side. Often specific stakeholders may have prejudices, disagreements with you, divergent viewpoints, political positions, and/or existing relationships with other companies. These need to be defused.

Complex IT needs

If there are complex IT needs, such as Kerberos integration, ideally make it clear that the client's IT department will be responsible for all client, server, and network configuration that will be needed to make it work. In particular with Kerberos make sure the client has responsibility to get a test page up showing Kerberos integration working.

Also find out about off-site access. If deployment and changes are only possible on-site, or if a subset of them are, this poses a big problem. Ideally try and secure a commitment to full remote access (drag and drop upload via e.g. FTP or SCP is ideal – Web VPN can make things very hard), but if they are nervous about it then consult with developers, add a lot of contingency, budget for travel time/costs, and explain that it means it may not always be possible to resolve problems quickly (we don't have a team of UK developers able to go on-site at short notice).

Find out any issues, such as Firewalls, proxy servers, thin clients (which make things like video or animation impossible, and may lead to other problems), and plan for them.

Find out what web browsers the clients use internally, and make supporting a certain set of browsers something written into the proposal (so they can't call up a contract dispute if some other browser doesn't work).

If on-site IT changes are something you need to do (e.g. they don't have an IT department) then make sure you are given full administrative network access, so that you aren't stuck between people trying to make things work.

Put in a payment structure for charging for problems stemming from their own IT architecture/management (e.g. call outs, and extra co-ordination).

Client is a designer

Do not agree a quote if the client is doing designs without first seeing the designs. It is common for third-party designs to be overly-elaborate, too extensive, and full of implied features, costing you huge amounts of time to implement or risking a failed project.

Client is a programmer

(Be aware I am writing this as a programmer – I don't intend to insult programmers as a profession, we create all this wonderful technology so should be respected for it!)

Something a good programmer thinks of easy and can be done in a few hours should from a business perspective be thought of as hard and a serious task requiring expert work and careful management. And thusly it needs to be charged as such.

Programmers often under-estimate the complexities that come up deploying work for others in complex environments, and good programmers often do not realise how skilled and knowledgeable they are and how valuable their own time is. Programmers usually even miss their own estimates.

Generally programmers will not appreciate the time in management, communication, testing, tuning, and general overhead, that comes from the more usual situation when client and developer are not one and the same. This is not surprising, given a programmer's job is not to know all details of project management. The overhead regrettably and unavoidably vastly exceeds the raw development time in this industry.

If the client is a programmer, or some other kind of engineer, a warning flag should be raised immediately. It is very likely that for any quote they expect far more than they will get because of their views on how long and hard things are. Therefore it is even more critical that the proposal is crystal clear and that you get them to read and agree to it.

Corporate processes

If you are obliged to follow special corporate processes, ensure these are clearly documented in a file located in the project directory. The file should be obvious and findable by anyone working on the project.

The quote will likely need to be multiplied up to cover the cost of implementing the extra processes, including ongoing/repeat training for them.

Taking over projects

If you are taking over a project another company has done then you should expect to find many problems, such as missing documentation, bugs, and low standards. You should not provide a quote until you have done an extensive code audit, which should potentially be chargeable separately.

Hiring developers

As a business, it is best to grow into demand, rather than ahead of it. To break even you will need to always be short of staff and having a back-log. This is the only way to operate with reasonable margins that customers would expect.

Training and Hiring are very challenging when applied to programmers. Training works for some professions. For example, to build a house you typical have a stonemason, a plumber, an electrician, a carpet fitter, etc etc. These are specialised skills anybody can learn through training, and you pretty much do the same thing every single day. Programming is not like that, programmers have to solve novel problems each day, and do fairly random tasks – therefore you can't train someone to be a good programmer, they need to be a 'special' (high IQ) kind of person right from the start, and that's the main thing. For example, imagine a programmer is asked to do an XLS export task – nobody is going to go on an XLS API training course, it's just one of countless random tasks that might suddenly be assigned to a programmer, and they need to problem solve on their own and learn quickly. So good programmers are a kind of person, you can't just train mediocre people (even existing programmers) into being good programmers. This is yet another reason why careful hiring and resource management is very important. This isn't to say programmers can't benefit from training courses, it's just saying you can't hire someone mediocre and expect to be able to train them to be great as a result of that.

Deciding on development schedules

Never make the mistake of putting a development schedule that simply reflects the time estimates used for costing. You need to add very considerable extra time to cover:

• when you can get started (you will have a back-log of work)
• contingency
• holidays
• hiring/firing issues
• covering the need for training / learning time
• illness
• ping time, as you go back and forth between staff (big problem if some developers are off-shore)
• task juggling time between projects, or pulling off staff for special missions
• other general kinds of unexpected delay
• impressing the client by how fast you are. Take the words of the greatest engineer in Future history:
  

  Scotty said

  [looks unbelieving] Oh. You didn't tell him how long it would REALLY take, did you?

  Lt. Commander Geordi La Forge said

  Of course I did.

  Scotty said

  Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

  (don't worry, this is just a joke – actually you just need to be very careful to not actually get their wrath for being late!)

Conversely, tasks often do get done in parallel (e.g. project management and development are done in parallel) which saves time. You probably don't want to tell a client that though, to keep things simple and reduce pressure.

A good usual equation for calculating time is multiplying the total costing time by 4. For example, if the development+design+management time is 25 working hours, then the schedule time would be 100 working hours.

Also, don't forget that for complex projects there will be a considerable 'integration time', making everything fit together, and then 'integration testing'. For example on an eCommerce community, a payment gateway might need integrating with a store, which would need integrating with design changes. Never underestimate how difficult this can be, things don't fit together perfectly and need to be adjusted. You often also find you can't test things to any proper degree until all the dependent components are done and integrated.

When deploying, always ensure that the deployment does not occur when developers and project managers are unavailable. This means that deployments should never occur before a weekend, or when holiday has been booked. If there is no alternative but to deploy at these times, ensure that all relevant staff are available on-call for disaster recovery purposes and that the project manager can be contacted by the client.

Hold strong

Some clients can be very demanding and pushy, so it's important to not be a push-over. For an experienced person there is a demarcation between providing good professional service and letting people walk all over you.

If you are forced to work over a weekend or evening, and it's not your fault that it is happening, you might charge a 50% premium for those hours.

If you are forced to incur unexpected costs (e.g. called out to an emergency meeting), you should be ready to charge for the time (including travel time) and travel costs.

Never let a client pay you "when they can afford to", never do projects on spec, and never like a client pay you in promised future referrals. If a client talks like this it should set off immediate warning signals.

See also

• Project pricing
• Maintaining a good agency relationship
• Project Management
• How to approach complex projects
• Choosing a software company for your project
• Minimum Viable Products

Feedback

Have a suggestion? Report an issue on the tracker.