Rules to Successful Projects

If you need to do something more than once, then there should be a standard for it. At the heart of our philosophy on creating rules and standards is the idea of consistency.

Whenever you're doing something more than once there should be a clear procedure. We call them “standards” or “rules”. That means that there should be lots of standards.

There are pros and cons to having standards:

We all want work that feels meaningful. When you focus on Autonomy, Mastery, and Purpose, you create an environment where people love what they do, grow their skills, and feel proud of their contribution. These three pillars not only motivate individuals but also build stronger, happier teams.

Projects often fail because clients think suppliers under-deliver and over-charge. The client and the supplier have different expectations about the goals of the project. This difference of opinion often leads to a project's absolute failure.

If you still need help, visit our Scrum consulting page and book in a consultant.

SSW's Rules to Better Scrum using Azure DevOps allows businesses to address their most important challenges first and respond quickly to change. Our rules advocate software consultants working on-site, or on the phone, so long as there is close consultation with business users, with the goal to become integrated members of the client's team.

The answer to this question can make or break contracts. We think that it's such a fundamental issue it has to be captured clearly. This is how we strictly define a bug.

Just like a car, applications need servicing and tuning every now and then to stay in top condition. They might need alterations to deal with new business problems, or just tuning to increase efficiency.

The first problem with specs is that nobody writes them. Joel Spolsky says:

> "Writing specs is like flossing: everyone agrees that it's a good thing, but nobody does it". > > - Joel Spolsky,  The Joel Test: 12 Steps to Better Code

The second problem is that when people do write them, they try and spec the whole project, spending months detailing every Use Case, Business Rule, and Process Flow Diagram. The client spends lots of money and sees no real progress, and the requirements change and the process begins again.

Developers often arrive at client meetings armed with a bunch of impressive software design and architecture documents. When they present these materials to the client, there is often confusion or difficulty in grasping the content. Even worse, walls of text may not be read.

Storyboarding solves this pain by giving the client a visual representation of requirements. This representation helps the client 'feel' the value and prevents miscommunications as the product is developed.

In every industry Market Research is conducted before a product is developed. Why is IT any different?

Doing Market Research focuses the product on the right set of people so you can satisfy their needs. If you can't connect the dots between the work you do and how it helps the customer, consider investing your time elsewhere. Market Research bridges the gap between the techies and the users.