SilverTree Systems - Adopting a new mindset

Adopting a situational mindset

How to reduce the cost of software solutions

Sometimes, tough times can provide the impetus needed to take a fresh look at how to get things done. This is certainly true when building software solutions.

How do you dramatically reduce the cost of building new applications? One way is to adopt a “situational” mindset towards building applications. A situational application is one that is highly focused on meeting the very specific needs of the problem at hand. Adopting a situational approach to building applications can reduce costs, save time, and make feasible solutions that could not be justified using a traditional approach.

Situational thinking goes along with cloud-based computing (which eliminates the need to procure, deploy and support the hardware and software required to support a new application) and the growing power of cloud-based application development environments (which significantly reduce the amount of time it takes to build a software solution). Add a situational mindset, and you get a game-changing way to develop and deliver software.

Traditional mindset

Situational mindset

Focus on “good enough”

The formal methodology of traditional applications favors a “big bang” approach – getting all the requirements, then programming, etc.

The goal is to produce something “good enough” of value as soon as possible, deploy it immediately, and refine it later if needed.

Embrace incrementalism

Because the overhead of starting up an IT project is so great, it only makes sense to tackle large projects with a significant payback.

A single custom application may not have the immediate impact of a packaged application, like ERP. But the incremental impact of a multitude of small situational applications can result in geometric growth in productivity.

Embrace messiness

Significant time is usually spent on getting the application looking like "packaged" software.

Highly adaptable systems may look sloppy. There is no point in wasting resources and energy trying to make something look beautiful if it’s not going to be around for very long or is going to change all the time.

Use simplifying assumptions

Because of the time and cost involved in starting up and building traditional applications, there is a need to try anticipate the needs of “any” user and anticipate every contingency.

When you aim your applications at a very specific target audience, assumptions that simplify the application can be made e.g. building applications without a lot of security, authentication, etc. because it will be used by a small user community who know and trust each other.

Get personal, don’t personalize

A significant amount of time and effort is often put into providing a way for users to “personalize” an application. This makes the application much more complex than if it were written for a specific use.

Make an application personal from its inception. The application should communicate that “this was built this for you".

Re-think ROI

Because of the significant cost involved, calculating ROI is essential.

The cost of justifying the return on investment for developing small applications will, in many cases, be more costly than developing the service in the first place. For example, no one would do an ROI for a spreadsheet.

Embrace change

Change is the enemy of traditional applications. Requirements are frozen in time, and are only changed with great reluctance, because change creates a cascading affect across the various roles involved in the process (QA, documentation, etc.).

Solutions are recognized from the start to be temporary and are treated as such. The system can be made to respond to any situation. There are few negatives to implementing change.

Underprescribe

The tendency in traditional development is to overprescribe – to think of all the possible exceptions and variations that might occur and cater for them when the system is written. This is important for applications where efficiency is key.

Most business processes involving knowledge workers are fluid and adaptable, so they cannot be too restrictive. This would also likely encourage rigidity due to a lack of desire to change the things needed to deal with exceptions. So the goal is to keep solutions “elegantly minimal”—to create “elbow room” for local interpretations and innovations.

Seek success

Traditional applications by their nature are focused on seeking to avoid failure and are concerned about keeping things status quo.

By being able to easily adapt, applications are focused on seeking success and finding new, better ways to perform tasks.

	Traditional mindset	Situational mindset
Focus on “good enough”	The formal methodology of traditional applications favors a “big bang” approach – getting all the requirements, then programming, etc.	The goal is to produce something “good enough” of value as soon as possible, deploy it immediately, and refine it later if needed.
Embrace incrementalism	Because the overhead of starting up an IT project is so great, it only makes sense to tackle large projects with a significant payback.	A single custom application may not have the immediate impact of a packaged application, like ERP. But the incremental impact of a multitude of small situational applications can result in geometric growth in productivity.
Embrace messiness	Significant time is usually spent on getting the application looking like "packaged" software.	Highly adaptable systems may look sloppy. There is no point in wasting resources and energy trying to make something look beautiful if it’s not going to be around for very long or is going to change all the time.
Use simplifying assumptions	Because of the time and cost involved in starting up and building traditional applications, there is a need to try anticipate the needs of “any” user and anticipate every contingency.	When you aim your applications at a very specific target audience, assumptions that simplify the application can be made e.g. building applications without a lot of security, authentication, etc. because it will be used by a small user community who know and trust each other.
Get personal, don’t personalize	A significant amount of time and effort is often put into providing a way for users to “personalize” an application. This makes the application much more complex than if it were written for a specific use.	Make an application personal from its inception. The application should communicate that “this was built this for you".
Re-think ROI	Because of the significant cost involved, calculating ROI is essential.	The cost of justifying the return on investment for developing small applications will, in many cases, be more costly than developing the service in the first place. For example, no one would do an ROI for a spreadsheet.
Embrace change	Change is the enemy of traditional applications. Requirements are frozen in time, and are only changed with great reluctance, because change creates a cascading affect across the various roles involved in the process (QA, documentation, etc.).	Solutions are recognized from the start to be temporary and are treated as such. The system can be made to respond to any situation. There are few negatives to implementing change.
Underprescribe	The tendency in traditional development is to overprescribe – to think of all the possible exceptions and variations that might occur and cater for them when the system is written. This is important for applications where efficiency is key.	Most business processes involving knowledge workers are fluid and adaptable, so they cannot be too restrictive. This would also likely encourage rigidity due to a lack of desire to change the things needed to deal with exceptions. So the goal is to keep solutions “elegantly minimal”—to create “elbow room” for local interpretations and innovations.
Seek success	Traditional applications by their nature are focused on seeking to avoid failure and are concerned about keeping things status quo.	By being able to easily adapt, applications are focused on seeking success and finding new, better ways to perform tasks.