Keeping Projects on Budget

BudgetYou know the drill.  Some ridiculously high percentage of software projects go over budget… And you’ve heard stories to back it up. Or worse, you have your own tales of being hung upside down by your ankles while the developers shake you down for every last cent.  Yet, here you are.  You’ve got a problem and it seems the only solution is custom software.  You’re doomed, right?  You might as well get ready to grin and bear it as you’re no doubt about to head down a path of endless pain and misery.  How did it ever come to this?

It doesn’t have to be this way!
I know… suspend disbelief for just a minute.  It’s going to take a lot of planning, coordination and hard work, but a well-executed software project can stay on budget AND deliver you a solution that satisfies your objectives in an effective and lasting way.  Here’s how we’ll help you do it:

Initial Sales Meetings and Preliminary Requirements Gathering
We start every engagement with an open mind. It’s important to fully understand all of the issues and goals before committing to any particular solution or technology.  Our initial meetings are designed to learn about your business and the issues you face.  What are the specific problems you are trying to solve and what are your goals?  Essentially, we start by helping you to define what success looks like for your project.  With that understanding our team will draft preliminary recommendations and deliver those with ballpark estimates.  At this point, we still won’t have all of the knowledge required to solve your problems, but we definitely have enough to determine if we are in the same ballpark… that is, determine whether or not we should continue before you spend any money.  If we are, the next steps will be to propose a formal Requirements Analysis process.

Requirements Analysis (RA) Phase
In this phase you’ll formally define what we are going to build.  We’ll schedule a number of meetings (preferably face-to-face) where our staff will spend time with your team to define the nitty-gritty details of the project. We’ll ask questions… I mean A LOT of questions.  We‘ll gain an understanding of your workflows, your staff, your business cycles, etc. so that we can clearly identify all of your needs.  With this deep understanding, we’ll produce several outputs that will help you effectively solve your issues within a predictable budget:

  • Business Requirements Document (BRD) – This is a comprehensive, plain-English, easy to understand definition of what you’re asking us to build. It can be read and understood by anyone on the project team, regardless of technical ability. The BRD is the cornerstone of the project and plays a fundamental role in sending you down a path where a predictable outcome and budget is possible.
  • Screen Mockups/Wireframes – These will provide a roughed-out visual representation of the system. They will help you to gain a better understanding of how the system will look, flow and feel.
  • Flowcharts – These are a visual representation of the workflow and business rules for the more complicated sections of the system.  They will help to further iron out the finer details of the project and identify “holes” early on.
  • Fixed fee for implementation – Once we know exactly “what” we’re building, we can very accurately predict how long it will take and how much it will cost.  That allows us to provide you with a fixed fee proposal for implementation.

In addition to these outputs, we will provide you with guidance on infrastructure needs, licensing for 3rd party components, and requirements for any 3rd party vendors, plus details on what your team will need to do to keep everything on track and make the project a success. Getting all of these issues on the table early and working together on a plan for dealing with them is the most important step towards a path that allows for a predictable budget.

The outputs from RA are yours to keep and are designed in such a way that any development shop with the appropriate technical abilities could implement them for you.  We certainly hope that you’ll choose to continue working with us, but at this point you are free and clear to move on if that’s what ‘s best for your organization.  And the best part… you’ve likely gotten here in less than 20% of your overall project budget.

Implementation
Once you agree to our fixed-fee proposal we’ll begin to implement your solution.  As far as the agreed upon scope is concerned, you won’t have anything to worry about in terms of budget.  We’ll produce the agreed upon output for thee agreed upon fee.  However, there may still be other costs that need to be managed.

Out of Scope (OOS)
We’ll continue to spend a lot of time with you during the implementation phase.  In particular, we’ll have regularly scheduled demos and walkthroughs that will allow you to see, feel and tweak the system throughout the process.  Minor adjustments to layout, appearance, terminology, etc. are expected and this is taken into account within your fixed fee.  However, you will inevitably identify additional opportunities for enhancements/changes that were not thought of during the RA phase.  Many of these items will be relegated to a future phase, but some may represent such a benefit to your solution that you choose to implement them now.  We’ll tap our vast project experience to help you classify the items and advise on how to best fit in those “must haves” with minimal impact to your timeline and budget.

Third Party Vendors
Very often you’ll have additional vendors that play roles in your solutions (i.e. your IT staff, your hosting company, the firm that supports the application you have asked us to integrate with, etc.).  This can create pressure on timelines and that can have an impact on your true costs (even if just by requiring additional time investment by your staff).  We’re very experienced in dealing with these situations and will advise you on how to get commitments from these parties and hold them accountable to meeting them.

Adoption
Once your software is complete, you need to get your users to use it.  This involves training, planning cut-overs, etc. and these things can definitely impact your true costs for the project. Having deployed hundreds of systems into organizations of all sizes under a wide array of circumstances, we’re able to advise you on a roll-out strategy that will help this all happen predictably (and on budget).

Quality Assurance (QA)
Your project has been in QA since the RA phase. Our QA team is tasked with reviewing and approving your Business Requirements before implementation can begin.  Then, the QA process continues through implementation with Code Reviews and internal screen reviews. Finally, the resulting software is put through a rigorous final QA pass that verifies all of your business rules and may include load tests, security scans, etc.  How does this impact the budget?  It’s all included in the fixed fee, but the value goes beyond that.  By ensuring a quality product goes out the door, we’re really enabling you to predict the long-term operating costs of the solution.  That will keep you “on-budget” for the long haul.

Ongoing Support
Depending on your specific situation, there’s a very good chance you’ll need or desire some level of support from our staff post-go-live.  With a full-time help desk and available 24x7x365 support solutions, we are equipped to provide you with a long-term support arrangement that meets your budget and business needs.

Deployment
Once everything is done, we still need to launch your software before you can start using it.  Delays of any kind will likely impact your total costs (i.e. think costs associated with preparing your staff for a launch that doesn’t happen, then doing it all over again a week later). Our development process takes a structured approach to this as well.  With thorough checklists in hand, our staff will be able to launch your software on schedule and will be less likely to run into last second “surprises”.

Summary
Our development process has been defined and tuned over the past 15 years through the experiences gained in thousands of engagements.  Our comprehensive approach, combined with the vast experience of our staff, allows us to identify and address hurdles early on and helps to eliminate the big “surprises” that plague so many software projects.  This allows predictability… And predictability saves budgets.

Advertisements

Finding The Best Technology Solution Shouldn’t Feel Like Herding Cats

The Value of Requirements Analysis

Sometimes it’s hard to remember that “problem” isn’t a dirty word. Your business solves problems every day; that’s why your customers come to you. Let’s start thinking of problems, not as bad things, but as opportunities.

Imagine that you’re considering a new line of business or you’ve found a process that causes a lot of friction, so you decide to change. You’re probably anxious and we can understand that; there are lots of ways to get off course when you charge a team with change:

  • Each team member goes after a different problem, so the solutions don’t converge. How do we get everyone back on the right page? What is the right page?
  • The project keeps growing and growing. As the team starts solving the problem, you find people adding new features to the solution. The team keeps looping back to revise the plan and each time you do, your budget grows. Nobody saw this coming. How do you stop it?
  • The team implements a solution. A few months go by; you analyze the data and find that the problem is still there. What happened?
  • The team proposes a solution. Senior decision makers hesitate because of budget, lack of in-house talent, or other priorities. Without buy-in, decision makers cancel the project. Does this mean you have to start over?
  • The team recommends a product to fix the problem. But once the product is in place, you find out there are some critical gaps in the solution. How can you bridge these gaps?

Here at Algonquin Studios, we have a process that prevents deviations like these. We call it “Requirements Analysis.” We begin by defining the core problem. We dig deep. We’ll humbly challenge your team by asking “Why?” and we won’t let you down by accepting the first answer as gospel. If there’s more than one problem, that’s OK; we’ll prioritize them. Working together, we’ll define exactly what your problems are and ask your whole team to commit to working on them.

Next, let’s propose solutions — lots of solutions. Don’t limit yourself to technology; you could change people, processes, and policies, too. After brainstorming, we’ll cull ideas together and judge our good ideas by doggedly adhering to the problem definition. A vision should surface — a vision of what your firm looks like operating the solution. You’ll feel good about committing to this vision and we’ll return to it again and again to overcome anticipated barriers and engage your team.

Now you’ve got a defined problem that’s simple to communicate and a vision for its solution. Algonquin Studios finds that these two key ingredients give you clarity, keep your team focused and gaining ground, and can nearly eliminate re-work costs from here on out.

After working through the initial Requirements Analysis (RA) phase detailed above you may determine that you need a new process, and some tools to operate it. By applying our detailed RA process at this stage, we can capture all of the business rules, inputs, outputs and processes to build or adapt those tools while honoring your decisions about scope, phases, and value trade-offs. We’ll start at a high level and break apart complicated processes until we reach simple, atomic ones. A solid detailed RA document becomes the foundation for planning, designing, building, deploying, and training for a good solution.

You might be surprised to find that a policy change is all that’s needed to solve the problem, so there’s nothing to build. And that’s a fine outcome!

We know this sounds potentially uncomfortable and like a lot of work. As a decision maker, you’re already living and breathing your problems every day and are hoping for a vendor to simply roll out the solution you’ve already got in mind. But what if there was a better way? A way to help make sure your solution is an unprecedented one that can grow your business like never before. That’s what we believe the RA process is, and it’s why we’re so committed to it here at Algonquin Studios.

Know Your Requirements!

Often times at Algonquin Studios, clients ask us to improve on their current software solution. The existing solution is either out of date or it simply isn’t giving the client what they need. For the user, changing systems can be a scary proposition. People grow comfortable with what they are accustomed to however, following a routine that you’ve done for years is the safe route. For this reason, it’s very important to sit back and think about what the system needs to accomplish. We want to make sure we maintain the output they are expecting from the software they use on a day to day basis, but keep an open mind on how to get there. In order to ensure this outcome, we spend a considerable amount of time conducting requirements analysis.

During the requirements analysis phase, one of the most important parts of a project, we determine what exactly the client needs are and how we will provide that solution. Time and again we run into the same obstacle of getting the client to see the difference between “what your users have today” and “what do you need the software to accomplish.” Clients often want everything they have today, in addition to the improvements we will provide with our software. Unfortunately, this could cause unnecessary features to be included in the software and add additional costs into the project going forward (training, support, system complexity … etc.). Costs that could be used elsewhere, either for the company or to build out additional features that are needed in the new system.

So, when coming into these requirements meetings it’s best to come prepared. To be better prepared it’s most important to know what is needed, as opposed to going screen by screen showing us everything they have today. There are many other ways to be prepared for these meetings, here are a couple:

Question your users

As a client, when was the last time you asked your user base about the program they use on a day to day basis? Requirements and business needs are always changing over time. Depending on the size of the user base, and the software being used, these questions could vary (and there are many). In the end, the client should find a way to determine:

  1. Which features are being used the most?
  2. Which features are rarely (if at all) used and aren’t needed?
  3. Is there anything you need the system to do that it doesn’t do today?
  4. Does the system provide repeatable work that the software doesn’t handle, costing people time every day?
  5. Are there current features that need to be revised to accommodate current needs?

There are many ways to gather this data.

Is this software internal, used by only a handful of people in your office? Have a meeting to review the software and gather the information firsthand from the users. Come prepared to ask about features that work and those that don’t. Are there any that have lost value over the years?

Do you have thousands of users using the software across the United States? Setup online user groups and invite people to provide valuable feedback on the software. Depending on the capabilities of your software, you can limit the groups to certain sections of the software and provide questionnaires about those sections. This should help you gather all the necessary information to bring to your developers, so we can make sure we build you an efficient, quality application that suits all your needs.

Clearly Define the Inputs/Outputs

Frequently, a screen can be so overloaded that one loses focus on what exactly is needed. Determine all the inputs of the screen and make sure they are all required and are what you need. Next, identify inputs that are unnecessary or misused. Keep in mind that just because they exist today doesn’t mean they’re needed going forward. Additional inputs only cause more complexity.

As important as it is to define the inputs, it’s equally important to define the outputs. Outputs that are currently delivered may no longer be needed or efficient or may simply be delivered differently in the new software; Once again, this is often difficult for a client to understand. Asking a lot of questions in the requirements meetings about those features can help ease the process because in the end, the more inputs/outputs you have the more complex your system will be. Our team of consultants are really good at letting clients know if the value they’ll receive from a feature is worth the effort and, generally, we can determine this during the requirements meeting.

In the end, if the client does their part in determining what’s exactly needed out of a system in order to eliminate all the old, antiquated screens and logic, the better the software will be. This will ultimately save the client in the long run.