Home / Tesserac UXD Blog / Controlling Budget
Controlling Budget

Controlling Budget

We are right to be worried about budget. Multiple studies justify our concerns: In 2004, the Standish Group reported that 71% of IT projects were over budget, while University of Oxford researchers found that large IT projects run 45% over budget, and an article in the Harvard Business Review in 2011 reported average overrun of 27%, but also brought up the fact that as many as one in six of the projects experienced cost overruns of 200% (they called these “black swans”... hmmm, pretty.)

Why Projects Go Over Budget

Causes for overruns typically fall into the following categories:

1. Underestimated complexity and/or volume.

Additional Volume:  More touch points mean more time, and in project land, time equals money.  More content to migrate, pages to edit, unique widgets to create, more slight variations of the same layout to code and more rounds of revisions to address. Of course there are efficiencies when executing similar repeating tasks, but even slight underestimates of volume can mean extra chunks of budget. Conducting a content audit and creating a complete set of wireframes can help realistically quantify the work being done as part of scoping and requirements gathering.

Additional Complexity:  It can significantly impact your budget when the level of effort required is discovered to be more than originally expected. This can come from underestimating, being too optimistic, or not being fully able to estimate unknown factors - such as new technologies, external data sources from yet unintegrated third party systems, or even just complicated workflows that are tricky to fully conceptualize on paper. When creating a project plan, it can help to flag these types of items as ‘high risk’ and consider allocating additional time to them for research and prototyping.

2. Assumptions about the feasibility or effectiveness of solutions.

Walk a mile in someones else's user journey before jumping to feature implementation conclusions. Solutions that are suggested before the target problems have been fully uncovered have the potential to put a budget at risk. A designated project planning phase allows time to collect valuable information from stakeholders and end users which can help maximise return on investment. If you begin designing solutions or committing to specific user interfaces and features before workshopping issues and goals with user experience professional or technical experts, you run the risk of making incorrect assumptions and often discounting some simple, yet effective work arounds. A full, 360-degree project discovery must involve multiple stakeholder groups, both quantitative and qualitative analytics, subject matter experts, communications and marketing, IT and end users.

3. Not allocating adequate time for non-design or development related activities.

Creating a realistic budget means including time for all project-related activities that will help move project forward. Plan on budgeting between 10-25% of total project hours for each of the following line items:

  • Research and planning
  • User experience design
  • Information architecture
  • Project management and communications
  • Quality assurance and testing

4. Changes to scope made when constraints are realised.

Drupal allows for adding features quickly, but often requires additional custom work to meet specialized or complex business requirements. Sometimes it’s only after features are built out, populated with content and tested out by real users is it discovered that they don't fully meet expectations or needs. When this found to be due to limitations in available community modules, the options are a) to simplify the logic and/or adjust the system so that it works within the constraints or b) add more budget to custom build precisely what is required. The best way to avoid these difficult choices late in a project is to carefully define only the “what” (the action that is required by the user to make the site successful) and not the “how” (or they way the system should address the business problem).  A good understanding of project constraints combined with a flexible approach to implementation will help open up possibilities for cost-effective solutions.

5. Changes to scope when conflicting priorities battle it out.

It can be challenging to set realistic expectations with large stakeholder groups, especially on a long overdue project. Everyone is excited about the blue sky of possibilities - and at the beginning, almost anything is possible - until budget comes into play. A project that needs to be all things to all people is in grave danger of going over budget - especially if there isn’t strong leadership to help direct priorities. A focused project vision with strong leadership and a designated product owner who has the authority and personality to be able to act as a disciplined gatekeeper to a barrage of requests is the best scenario for projects that need to answer to a large group of interested parties. It’s also important to have a clearly defined change management process and acceptance criteria, especially for subjective or difficult to describe aspects of the product, such as visual design and ‘ease of use’.

Five keys to controlling budget

In the end, we just want to know if we have enough budget to get what we need. No one likes surprises or an ever-expanding bill, so how can we protect against the very real danger of things costing more than hoped or expected? Here are five key factors. These best practices will need to be approached differently depending on whether you are in the planning or development phases of the project, but following them from initial specification writing to monitoring and controlling buildout, through to quality assurance and launch will yield excellent results. For optimal success, be sure to also seek guidance and input from a multidisciplinary team who is experienced in budget control techniques.

  1. Clearly defined and well-researched target problems
  2. Realistic project goals
  3. Good understanding of project constraints
  4. Clearly defined change management process and acceptance criteria
  5. Strong leadership, direction and product ownership

Obviously, creating a realistic budget in the first place will make it easier to manage expenses later, in the development phase. For more information on best practices for requirements gathering, check out our two-part blog post on the topic.

Originally published on drupalconnect.com