- Details
- Written by: Dustin Rocksvold
- Category: General
- Hits: 1
Introduction
Many projects fail long before a single line of code is written.
The root cause is often poor requirements gathering.
When requirements are misunderstood, incomplete, or rushed, the resulting solution may solve the wrong problem entirely.
The Solution Trap
One of the most common mistakes is proposing a solution before fully understanding the problem.
Consider the following statement:
We need a mobile application.
Do we really?
Or do we need faster access to information?
A mobile application may be one possible solution, but it should not become the starting point of the conversation.
The Importance of Questions
Good requirements gathering involves asking questions.
Lots of questions.
Questions such as:
- What problem are we trying to solve?
- Who is affected?
- How is the process performed today?
- What are the biggest pain points?
- What would success look like?
The better the questions, the better the eventual solution.
The Hidden Costs of Poor Requirements
Poor requirements often lead to:
- Cost overruns
- Scope creep
- Delays
- User dissatisfaction
- Rework
Each of these consequences can be far more expensive than spending additional time understanding the problem upfront.
Closing Thoughts
Technology can solve many problems.
The challenge is making sure we're solving the right one.
- Details
- Written by: Dustin Rocksvold
- Category: General
- Hits: 2
Introduction
Organizations often jump directly into building new solutions.
Before doing so, it may be helpful to pause and ask a few important questions.
1. Does a Solution Already Exist?
The fastest solution is often the one that's already available.
Before building something new, investigate whether an existing solution can meet the need.
2. Can an Existing Solution Be Extended?
A solution may not meet every requirement today.
However, a small enhancement may be easier and less expensive than creating a completely new system.
3. Can Components Be Reused?
Many organizations possess valuable building blocks.
Workflows, reports, databases, templates, and integrations may already exist.
Reuse is often more efficient than recreation.
4. Is the Problem Clearly Understood?
If stakeholders cannot clearly explain the problem, development should probably not begin.
An unclear problem almost always leads to an unclear solution.
5. Is Custom Development Really Necessary?
Custom development introduces long-term responsibilities.
Someone must support, maintain, secure, and update the system.
In many cases, configuration may be preferable to customization.
Closing Thoughts
Building something new should be the last question, not the first.
- Details
- Written by: Dustin Rocksvold
- Category: General
- Hits: 2
Introduction
As technology advances, organizations have access to more data than ever before.
Yet many still struggle to make better decisions.
Why?
Because data alone is not enough.
Data
Data consists of raw facts.
Examples:
- Reservoir elevation
- Water flow
- Temperature
- Production output
By themselves, these values have limited meaning.
Information
Information provides context.
When data is organized and presented in a meaningful way, it becomes information.
For example:
Reservoir elevation is decreasing at a rate of 100 acre-feet per day.
Now the data tells a story.
- Details
- Written by: Dustin Rocksvold
- Category: General
- Hits: 2
Introduction
Many organizations have extensive documentation.
Shared drives.
Wikis.
SharePoint sites.
Knowledge bases.
Thousands of documents.
Yet employees still struggle to find the information they need.
The Illusion of Documentation
Documentation creates a comforting illusion.
Leaders see thousands of documents and assume knowledge has been preserved.
However, stored information and accessible information are not necessarily the same thing.
- Details
- Written by: Dustin Rocksvold
- Category: General
- Hits: 2
Introduction
Every organization likes to believe it learns from experience. Unfortunately, many organizations end up learning the same lessons over and over again.
A problem appears. Someone develops a solution. The solution works. Time passes. Team members move on. Documentation gets buried. Knowledge fades.
Then, years later, another team encounters the same problem and begins building a new solution without realizing one already exists.
Sound familiar?
The Reinvention Cycle
The cycle usually looks something like this:
- A problem is identified.
- A solution is developed.
- The solution is deployed.
- Knowledge about the solution gradually fades.
- New personnel arrive.
- The problem reappears.
- Another solution is built.
The organization spends time, money, and effort solving a problem that may have already been solved years before.
Read more: Why Organizations Keep Reinventing the Same Solutions?
Certifications
