- What We Do
- Our Work
- News & Events
We have worked with hundreds of software systems, and specialize in a select few. We provide software recommendations based on a thorough understanding of our clients’ need and we don’t play favorites with the technology.
All technology projects begin with gaining clarity, specificity, and consensus on the needs that form the impetus for the project.
Understanding our client’s functional needs is critical so that we can suggest the optimal technical solution. Many clients come to Confluence with a first draft of their requirements–each requirement tends to correspond to a current pain point within their technical workflow or system.
We begin the Requirements Definition by either crafting or responding to a list of functional needs. In this stage, we discuss options with our clients for how certain features may work or look. We find this phase is often a very exciting and empowering experience for the client. After the operation of each functional area has been finalized, all decisions will be cataloged in the requirements document. This is a “living document”. It is natural for changes to be desired as the project progresses. Changes go through a simple, but formal change review process – to assess any impact on the cost, schedule, or potential for interaction with other requirements. If the change is approved, the requirements document is updated and a new version created. Time spent in this up-front task is instrumental in the success of the implementation and in keeping all projects on budget. Completion of the requirements document leads us into development.
Depending on the size of the project, our development team (with input from the client) may choose to structure the work as either agile development or waterfall. We believe that each methodology has its respective pros and cons and some projects more easily fall into one or the other.
Confluence’s implementation methodology includes peer testing as a standard part of all project plans. In this model, the documented requirements are used to guide a separate check to validate that the site operates as expected. After the peer testing is completed, we release the site or tool to the client for testing. A shared Google Doc is used to track issues and their status. We provide an orientation in advance of testing – helping to educate our clients on the basics – for example, that only reproducible issues can be debugged, so details must be provided with the issue to enable the programming staff to see the behavior. All template code is validated against the W3C validator and tested for quality assurance on PC and Macs in the two latest versions of all popular browsers.
A Project Manager who is responsible for client communication, regular check-ins, schedule and budget oversight, and quality assurance oversees all projects.