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:
- If you want to be able to generate an output, you must make sure you collect that information.
- Not everything is data, but anything you want to count, organize, summarize, graph, chart, or tally needs to be treated like data.
- Collecting data means putting restrictions on the users. The opposite of collecting data is writing a report.
- Projects need significantly more planning time, but the payoff is significantly less reporting and data management.
- 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:
- 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.
- 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.
- 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:
- Who will be the users of this system?
- Do users have all the information we need input into the system?
- How often do I expect people to use this system?
- 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