At Slater Hill, we're tenacious problem solvers first, and technologists second. We define the business problem, prioritize and plan, and then rapidly deliver the early "rough drafts" of a technology solution.
Define vision, goals and constraints
Analyze & Plan
Project planning, communication plan, training plan, migration plan.
Carry out workshops
Prepare & Validate
Configure solution and invite pilot users.
Iterative feedback and change
Fill solution with content.
Training, communication and migration.
Hand over & Close
Solution handover to customer and governance team
We don't try to show off that we know the latest technology, or try to hammer square software into a round business problem. Before proposing a solution, we dig deep and discover the real business problem we're trying to solve. Then we select the tools and technologies that will return the best value.
At Slater Hill we don't believe in "Not Invented Here". We know that custom software is expensive to write, and even more expensive to maintain over time.
In the age-old "Buy-versus-Build" debate, we usually come down on the side of 'Buy.' We don't suggest custom code when a third party has already solved the problem. Why not let the cost of development, testing, bug-fixing and support be spread over hundreds of organizations OTHER than yours?
"Don't reinvent the wheel" also means being smart about reusing frameworks, documents, tools and libraries that have worked in the past. We focus on the business problem at hand, not the technical details of logging or caching. For you, that translates to faster time-to-value.
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Many IT pros forget that not everyone who looks at a solution is an IT pro.
Not Slater Hill. We never make assumptions. Many pairs of eyes look at our software solutions, constantly asking: WHO is the intended audience? Is this intuitive for those users? Does it look and behave as they expect? If we don't know the answer, we ask the client. Often.
How do we do this? Mostly by putting working drafts in front of users as early and as frequently as possible. We make solutions for people, not "personas".