Working Together

 Openflows does things differently than most technology companies, and that’s why our clients choose to work with us. 
Along with being a cooperative, we do the following:
  • We start each project with a discovery and planning phase
  • We ask our clients about their process, work styles, capacity and desired scope, resulting in a more client-focused end produce
  • We ask your input on your needs, and advise you as to the process and cost to create that function technically.
  • We focus on long-term relationships with our clients
  1.  We are different because we focus on long term relationships rather than one-off projects. We strive to complete projects and not leave people in a lurch. We seek to work with you to find a balance between budget, timeline, scope, and order of priorities throughout the project and into the future.
  2. Our methodology allows for a slower more encompassing approach. We do not build “websites,” we build well thought out organizational systems based on a transparent and interactive process with the client. we move fast when we can and we slow down and let the client absorb what has been done. And in this way we allow the client to remain in control over the development of their software.
  3. We ask our clients to realize that not only is every project unique, but in nearly all our projects — because we are building in such a client centric way — we are building something that has never been built before Therefore we ask our clients to understand that while we do our best to define labor estimates and project timelines that it is impossible for those estimates to be accurate in every case. We do our best to keep the client informed as soon as possible as changes to estimates or timelines become possible.  As well, as the project moves along we’re responding to your feedback as you use a software you’ve never had before and there are many times where the client’s feedback changes the scope of the project. We do our best to respond to those changes with minimum disruption to the process but at times we ask the client to understand that these changes in focus and scope will often require revisiting labor estimates and timelines.
  4. We use human language work agreement and not lawyerly contracts to make old fashioned agreements.
  5. Our planning and discovery phase is separate from the development phase and billed as such. This allows us to engage with the client and do the necessary research so that we can give more accurate estimates based on the knowledge and insight that we gain. Those who give estimates without doing the proper research and discovery, end up doing this work and billing for it later in the process. We like to do it as a first step because it allows us to be transparent with the client, provide the client with choices based on our discoveries, and lets the client make decisions regarding project scope based on their priorities.
Complex systems often require an iterative approach to development: we plan the scope and tech specs, clients approve; we develop, our clients review, clients request changes and innovate new requests; we plan, clients approve, we develop, clients review, clients request changes and innovate new requests; we plan, clients approve, we develop, clients approve, and innovate new requests …
Milestone-driven development
  • We implement both Planning Milestones and Development Milestones. Before development: what do you need?
  •  After development: what does having this tool now change about your workflow and what you now need?
  • We break our projects into milestones: chunks of work that go together. We do the development for each a milestone, test/QA, and get signoff. Then, we review the scope as it stands. If the needs or requests have changed, we either change order or – if the project truly changes, re-plan and …
We prefer to start projects with a detailed and collaborative planing phase where the features, requirements and details of the project are defined. We have found that this methodology works better than trying to have us respond to a fully detailed RFP, where you try to imagine all possibilities before anything has been built. (see for some interesting thoughts on why we feel organizations should move away from the RFP model).