Tips
How can I tell if a technology project is being technology driven rather than stakeholder driven?
Our current "hot topic" urges that technology should not be the driver of technology implementation. So how do we identify whether or not a project is technology-driven, and if it is, what can we do about it?
Corrective Action
It is likely that there are people in every organization who understand the three steps for successful technology implementation (as described on the Hot Topic page) but they may be in a minority and unable to make their voice heard to senior decision-makers who are sometimes enamoured with technology. The approach of the leader in such a circumstance should be to show the situation for what it is. Following the Letts example in Leadership for Results, we need to create a data table and a conclusions table.
Create a Data Table
A key source for the data table is the project documentation. Review the purposes expressed and check these against the intended actions. As in the Letts example, it's likely that taken one by one the signs we see are small, almost trivial. But taken together, in the light of the best practice embodied in the three steps (given on the Hot Topic page) they indicate a high level of risk.
For example the strategic purposes may be
- "..access and services designed from the perspective of the public "
- "new electronic capacity to track the full customer service experience and make it easier for staff to resolve problems on behalf of the public when they occur."
Hence the organization shows a clear intent to follow the 3 steps. Yet a comparison with later documents may reveal that the project is no longer focused on this intent.
Conduct a Data Comparison
As a simple data comparison exercise we could compare the frequency of certain key words and phrases, important in steps 1-3, between strategy documents and implementation documents.
The words or phrases used for comparison could be:
- Customer (or public, callers, users)
- Staff (or teams, employees)
- Processes (or high level, workflow analysis, call flow, business flow, workflow)
- Requirements
- Systems (or new, upgrades, existing work order)
- Contact Centre (or consolidated, structure, model, new model, draft model, call centre, to-be model, call centre model).
A comparison of word counts gives us a data table:
Key Word | Frequency in Strategy Documents | Frequency in Implementation Documents |
Customer | 27 | 0 |
Staff | 0 | 11 |
Processes | 16 | 10 |
Requirements | 1 | 7 |
Systems | 6 | 1 |
Contact Centre | 9 | 25 |
Draw Conclusions
Such a comparison shows a clear shift away from a purpose of improving customer service towards a purpose of implementing technology. While this is not guaranteed to turn the tide of opinion, as the Letts example shows, it can be a powerful tool in the right context for getting decision makers to step back and take another look.