Home » Approach
Approach
This section describes our approach to any work that we take on. More on our framing and initiation of projects can be found under...Projects.
Summary
We take a 'best-of-breed' approach to projects, using the best-fit of techniques, scaled to fit the size of project.
- Client-led requirements gathering, specification and design
- Formalised (but flexible) project management producing:
- plans
- phasing
- resource allocation
- costing
- Realistic estimating and scheduling
- Client-led design and development
We follow the essentially same method for process re-design and software development
Project Planning (continuous)
No project can hope to succeed without a project plan; no project plan is of value unless it is constantly monitored and updated.
Amethyst uses proven techniques from PRINCE and DSDM to;
- produce initial scoping statement
- produce task-list, estimate resourcing and delivery dates
- produce a detailed project plan (schedule)
- monitor, maintain, revise plans and estimates
- frequently check-point and report back to client on progress
Requirements Gathering Phase
A business requirement defined is:
“What will it take to continue to run our business and what is it that we are looking to improve upon.”
A Business Requirement, in simple terms, can be “WHAT you want to achieve in this change programme.”
How do we do this?
- Background information. If you have a Requirements Document or a Functional Specification, that’s a great place to start. Other documents may provide similar background on your history and goals.
- Interviews of personnel at all levels and every function within the business units that ultimately will be impacted by your proposed business change programme. Focus groups may be useful to get information from real or potential users.
Staff (or User) involvement at this stage is crucial to an effective requirements gathering exercise
- User definitions and scenarios. Two of the most important questions are "Who's using the product?" and "What are they going to do?" We answer these questions by making a list of the typical users and writing usage scenarios about what they'll be doing with the product. Scenarios should be generic, not focusing on specific technology details; think about what tasks and features are involved because you can't write a story without sufficient detail.
This may lead to a couple of hundred requirements, but don't be alarmed, for the next step is:
- Classify requirements (must have vs. “wish list” items)
- prioritise requirements - always try to identify business critical processes and functionality.
Each requirement should be ranked and measured on the criticality of its business function.
- gap analysis - where we map the business processes and create
- an “As-Is” scenario (how you do your business today) then
- a “To-Be” (how you want to be doing things) and identify the gaps.
- the “Gaps” are then filled with the solution - be it a process change or appropriate piece of software.
However, what you often find is that the business requirement gathering process exposes holes in the process that need to be repaired prior to any other changes - process, organisation or software solution can be implemented.
Successful Business Requirements Analysis entails
- Understanding what the organization's business goals and objectives are;
- Determining what metrics are used to monitor those goals and objectives;
- Breaking down those metrics into natural language descriptions and their component parts.
How big a task is this?
The business requirements are not proportional to the SIZE of the company. A small company may have identified many Business requirements for its business initiative while a large company may not have that many. All depends on the company's business model and again WHAT it would like to focus on in the change programme.
The Design Phase
We will develop, review and test prototypes iteratively. They become more complete and accurate as time goes on. Usability testing helps validate our assumptions
Group prototyping exercises. Some of the ideas that your team has may be hard to articulate. In this step, we pick some of the important topics from the brainstorming exercise and sketch out what the solutions might be. We work in small groups, and it always draws out vital information.
Clients recognise that walking through scenarios and sketching ideas makes them think from their customers' point of view, rather than think, “I know all about that”.
Concept development. There are countless ways to design anything. We will narrow down the choices and present a few for you to review. Together, we'll select the best features of each and start creating the design
Information architecture. We'll create a site map that outlines the Web site (similar things can be done for desktop software). This is a good way to review the structure of your product before we invest time in design.
Interactive prototypes. Rather than just give you schematic designs, we like to create interactive prototypes. These can be done in a variety of way. More detail on prototypes. A recent client found that the interactive HTML prototype helped the development team understand how the product would work. It was considered part of the design specification.
Visual design. It's important to have a professional designer create graphics and specify layout, color and typography. This does more than make the product pretty; good visual design supports the interactions that we work hard to create. You've probably seen examples of pages that were so busy you couldn't figure out where to start; that's frequently the result of ignoring the visual design. The visual designer can start developing ideas at any time, but we tend to wait until the features are reasonably specified. This way we know how much information is required and how it all relates.
Usability testing. There's nothing like watching real users work on your product. It's sometimes very humbling. We can run studies on anything from paper prototypes to finished software.
The Delivery Phase
The delivery phase consists of:
Product specification - documenting what's to be delivered. Consulting engagements are usually brief. It's helpful if you have a decent spec to refer to after we've completed our work. If it's software, that can be anything from annotated screen shots to a formal document that indicates clearly what every on-screen element is, what it does and how to move around the product. If it's change management, then the 'spec' is the change plan, process maps and organisation chart
Commission - Amethyst can, where additional skills and personnel are needed, advise, commission or recruit top developers and specialists to complete the programme.
Build - develop the processes, organisation and software systems to complete the programme
Test - prove the solution works, is error-free, robust and up to quality standards
Train - educate client staff in processes and software as neededGo-live - plan and oversee the implementation process, including post-implementation review and modification to processes and software as practical experience requires.
