Questions? Call us: 1-800-214-7060

The Rules to Successful TEBS Project Implementation

September 11, 2013 - Kestrel Management • dynaQ

What Is TEBS?

At Kestrel, we are changing the way traditional consulting is delivered by viewing all of our projects as TEBS projects…that is, Technology-Enabled Business Solutions (a/k/a TEBS).

To help our clients understand our TEBS approach, we’ll be defining critical steps and general rules to live by when working with technology over a series of blog articles.

5 Key Rules

Here’s a preview of the 5 key rules and the articles to come:

  1. If you want to be able to generate an output, you must make sure you collect that information.
  2. Not everything is data, but anything you want to count, organize, summarize, graph, chart, or tally needs to be treated like data.
  3. Collecting data means putting restrictions on the users. The opposite of collecting data is writing a report.
  4. Projects need significantly more planning time, but the payoff is significantly less reporting and data management.
  5. Systems need to be able to grow and expand to accommodate changing data needs.

Keep reading for more on Rule 1…

Rule 1: Any output must first be input.

It seems so obvious, yet it is Rule 1 for a reason. For people who are not deep into technology, there is a noticeable gap between what they want and what they are willing to invest into input. It is easy to determine all the data needs of a system, but it can be quite challenging to get all users to input the information in a timely and complete manner. Without the information, the value of the output diminishes greatly.

Outputs take a lot of different forms. For instance an email notification could be an output of a system. Other outputs include Excel spreadsheet, PDF report, bar chart visible in the browser, and a visual ‘red flag’ in the program.

Rule 1: In Action

Take this real-world project as an example…   A client indicated to us that they would like a system to notify when projects are coming up and overdue. It seems like a simple request, but it is important to note what this required:

  1. All projects must have a due date. If projects are broken into sub-projects, those need due dates, as well. Users need to track those due dates and change them if the project changes. This need led the client to request a notification if a due date changes so users won’t be able to bypass the notification system after a project is approved.
  2. The system needs a way to notify on a different schedule depending on the importance of the project. Critical projects need 30-days notice and minor projects are okay with 3-days notice. This requires the users to assign a project importance and track how many days notice are required for each level of importance.
  3. Finally, the system needs a way to have users check off tasks as being “complete” so that overdue notices are no longer sent.

Rule 1: Take-Aways

These are not technical challenges; rather, they are challenges in how much you can expect system users to use that system for the day-to-day management of a particular purpose. Given this, it becomes critical to ask the following questions at the start of the project:

  1. Who will be the users of this system?
  2. Do users have all the information we need input into the system?
  3. How often do I expect people to use this system?
  4. Do the outputs meet the goals for making this process more efficient and more effective?

Stay tuned for Rule #2: Not everything is data, but anything you want to count, organize, summarize, graph, chart, or tally needs to be treated like data.

Submitted by: Evan Fitzgerald

Insights & Updates

  • Categories

  • Archives