Wrong Tool, Right Solution
When there’s reasons we can’t “do it right” we need to get creative
We’ve all been in the situation where we know what needs to be done, but there’s something blocking us from getting it done. Often it’s time, budget, scope, authority or politics. Political blockers are tricky to navigate because the ability to work well together in the future is dependent not only on successfully completing the project, but doing so while playing to the proper egos and avoiding stepping on certain toes. Sometimes that means finding an unconventional solution to a straightforward problem.
The TV show ‘MacGuyver’ has loaned us its name, used when we improvise an inventive solution using whatever items are at hand. Often it has loaded meaning, both complimentary about the creativity and negative implying that it’s a makeshift solution.
More importantly, the show not only shows ingenuity, it repeats themes about flexible thinking, building positive relationships, understanding the problem by looking at surrounding information, and solving the underlying need rather than the stated problem.
“Another day, a whole new set of possibilities” – MacGuyver
Years ago, in the technological dark ages of the early 2000s, I’d taken a role as “web coordinator” with a university faculty. I was excited by this vague title, because people were “going online” as part of their jobs for the first time. At the time most IT was run from dedicated servers or software on individual computers. Microsoft Office still dominated, communication was done via Word documents sent by email, and “I’m not good with computers” was an acceptable excuse for staff to ignore tasks they didn’t want to do.
I found this exciting! As the website became more and more popular, students and staff expected more information to be delivered online. With more staff wanting or needing to contribute to the website, the individual support I was giving should have stretched me thinner and thinner.I avoided this by automating much of my work and by empowering the users to do their work directly rather than needing it to go through me.
Freeing up my time allowed me to build a personal relationship with every active contributor, and continue to automate even more necessary tasks. The benefits of automating manual business processes and tasks cannot be overstated!
By the time my department merged with another large department I had a full time assistant and we were already supporting around 200 active contributors of varying technical levels. Our workload was about to double, and it was clear that we were in dire need of an upgrade to handle the additional workload. We needed something:
- Intuitive enough so all staff could comfortably edit content
- Streamlined enough to manage a site-wide template
- Able to grant varying amounts of access for different users
- Discoverable, so staff could start contributing without me needing to contact them first or vice versa
The “correct” solution, given the technology of the time, was a Content Management System (CMS) – the right CMS would meet all these requirements and more. There was an initial cost for setup and to transition that was easily justified by the benefits. The solution seemed like a win-win and a no brainer. Then politics struck!
Right Decision, Wrong Outcome
“We all get our priorities messed up once in a while.” – MacGyver
This growing interest in “the web” and the University’s website was not restricted to only the faculty where I was working. The other departments’ web coordinators and I had already informally formed a working group, attended monthly meetings, and had cooperatively designed a University-wide website identity and navigation. Despite this cooperation, there was a clear need to establish better governance and provide better infrastructure and support to all the varying web coordinators.
Thus, the “Web Team” within the Marketing Department was founded!
This new team immediately busied themselves writing one-sided contracts to establish their authority, giving themselves broadly defined jobs that didn’t commit to delivering anything specific, and granting themselves authority to override other groups’ decisions. To replace the existing working group we’d previously formed, they created a “Web Coordinators” committee that they would “consult with.” They were careful to avoid any wording where this committee had any authority beyond making “recommendations.”
“What they don’t know, will help us.” – MacGyver
Although we didn’t need any assistance, as a member of this committee and trying to be cooperative, I informed the committee of our workload situation and the need for a CMS. I offered to send over our research about which CMS we were planning to use and why, as well as our transition plan. We needed this CMS now – my assistant and I were spending almost all of our time supporting the current users, and had little left to take on new work from the web team’s upcoming changes.
We viewed this as a golden opportunity to solve this problem for more than just our one faculty. As part of a new committee that could contribute to this discussion, we could implement a CMS that could be broadly used by the entire University. Perhaps our dream of a unified website could finally come true!
“Typical. Just when you’re getting ahead, someone changes the odds.” – MacGyver
That was my fatal mistake, and when I hit the political brick wall. The web team wanted to decide on a CMS, install and host it, and then move everyone else onto “their” system. They wanted to start their research from scratch, make their own assessments, and then inform us of their progress. Of course, the committee would be “consulted” at every step, and would “help make the decisions” along the way.
The timeline was hazy, and their CMS “wouldn’t be ready for at least two years.”
In the meantime we were told that we “would not be allowed to implement our own CMS.” Apparently, so their argument went, if we already have a CMS in place it would make the transition to their CMS harder. I don’t think that any of the committee members understood why, and pointed out that we were already considering a CMS that would allow us to export the website content in multiple formats and should make importing it into another CMS easier. That should make moving the website much easier than if we transitioned the current website. Transitioning to a CMS while waiting for their solution would also allow our users to become familiar with the basic concepts, allow us to analyse their usage, and provide better usage requirements for the final central CMS.
Unfortunately, our “recommendation” from the Web Coordinators Committee changed nothing, and the edict remained: “No CMS or new technology can be implemented until our CMS is ready for use. After that point, any new technology can be requested from us, and if approved we will implement it.”
What could we do? We NEEDED a CMS, but we were not allowed one.
We could ignore them and implement our CMS anyway, challenging their leadership. Perhaps that would have been the best choice, but until now the various IT teams had worked cooperatively. We didn’t want to risk that dynamic.
Emotions, Not Technology
“Sometimes things are hidden under the surface. You just gotta know how to bring ‘em out.” – MacGuyver
Successful IT projects are rarely successful because of the technology. My belief is that projects are more likely to be successful when there is a specific problem that needs to be solved, the requirements for solving that problem are clearly identified, and the emotions of the various stakeholders are well understood and addressed.
Emotions matter in IT, because projects often need support across a range of staff who won’t be the ones benefiting. For various reasons, some individuals will want the project to fail – not because they are bad people, but because they worry that the project is going to cost them in some way – additional work, loss of control or authority, IT resources funneled away from the projects they feel are more important, and so on.
“I say we trust our instincts, go with our gut. You can’t program that. That’s our edge.” – MacGyver
While understanding the emotions and motivations of everyone involved is impossible, it’s still valuable to estimate the possible motivations of the various decision makers. Having a rough idea what drives the decisions allows us to look for win-win solutions that are more likely to be accepted. And isn’t that the goal? We aren’t in a battle with other staff members, trying to exert our will upon them. We’re in a boat together, and can achieve so much more if we row in the same direction.
We assumed it was likely the Web Team hoped to deliver a large, University-wide project that would show the value of their team, allow them to regularly report progress to upper management, and require an ongoing support team that justifies their ongoing cost. Whether or not they already planned to implement a CRM, by bringing our needs to the committee we had demonstrated the value of this project.
Therefore, if we implemented our own CRM without requesting additional funding or staff the value of their implementation would be reduced. Users would also compare their implementation to their current CRM, and may demand they match specific features or complain that their CRM is a step backwards.
Fear-based Management Decisions
Our conclusion: this decision was driven by fear.
Fear that robust requirement gathering would make implementation harder. Fear that there would be a comparison between the two systems and theirs would be lacking. Fear that the website coordinators would not respect their authority, nor follow their orders. Fear that they were unnecessary after all.
“You can’t just talk about your problems: you have to look for solutions.” – Lisa (MacGyver)
With this in mind, we looked for ways we could support their team. If they were driven by fear, was it possible that we could help?
Support, Not Opposition
“A good relationship is a lot like a car. If you want it to work smoothly, you gotta put a lot of work into it, and have the right tools.” – MacGyver
At the time, we considered this to be an extremely pessimistic conclusion and believed that the truth was likely much milder. However, taking the pessimistic view seemed sensible, because if we were right we could help support their team, and if we were wrong then this support might be unnecessary but wouldn’t create any problems.
We made use of the resources they had available, requesting help where they had expertise. We did genuinely value their contributions, and not only let them know directly but also promoted any projects they assisted with, prominently mentioning them in online articles.
We could not move ahead with the CRM, but we needed to move ahead with a solution for our problem. The need was all the more urgent, as we’d also taken on the work this Web Team was requesting, in addition to prioritising projects that could showcase their expertise.
A Rose By Any Other Name…
Although a CRM was the “correct” tool that met all our requirements, it’s just a term for a system that organises and displays content. There was no technical reason why the features needed to be delivered packaged together in a single new system. Instead, we could add additional code to our existing website until we had created the features we needed.
“I’ve found from past experiences that the tighter your plan, the more likely you are to run into something unpredictable.” – MacGyver
- Discoverable, so staff could start contributing without me needing to contact them first
Our website was a collection of static HTML files hosted on our webserver. It was already branded and templated, and I had already automated updates for the brand templates. So I updated our site to add an “Edit Page” link in the page footer. Clicking that link would allow the staff member to log in using their standard University ID and password. If they did not have access to edit that webpage, they were shown an online access request form.
- Able to grant varying amounts of access for different users
Once they were logged in, the address of the page they came from was checked against an access list. It would start with the full path, then walk “down the tree.” This allowed me to grant access ranging from one specific page to the entire website.
- Intuitive enough so all staff could comfortably edit content
If they did have access, the HTML from their page was retrieved and the title and content section was displayed in a visual editor. Staff could edit the page using an editor that looked a lot like MS Word, which they were already familiar with. They also had the option to switch to HTML mode and write the code directly.
Because mistakes happen, whenever an update was saved the system would compare the new page to the old page, and save a log of the changes along with the staff member’s ID. This allowed staff to restore the current page to an earlier point if they made a mistake.
Allowing staff to see the dates and view older revisions of the page gave them more confidence to remove content, knowing they could still view and replace it at any time. This was particularly useful for seasonal content, such as information about exams or new student inductions.
Once it was easy to see an error, click “edit” and update the text, many staff that were previously not involved with the website started correcting errors and improving content.
As this was technically a stand-alone single-page script, and “only” edited the content in an existing file, it wasn’t considered a “system”, “project”, or anything else that fell into one of the formal IT governance categories. Instead it was standard IT business as usual, and fell within the scope of responsibilities for our local group.
So… did it work?
“If you don’t have the right equipment for the job, you just have to make it yourself.” – MacGyver
Yes. It worked, but it wasn’t perfect.
Overall, it was a huge success – most staff found it much easier to use. There was an initial flood of access requests, many from staff members I had never met before, allowing my team to contact and meet new people who wanted to contribute.
Our maintenance and support workload plummeted, freeing those hours for other tasks. This also increased our job satisfaction, and we could spend a greater portion of our time on more challenging work. Our conversations with users became deeper – with the ease of editing content directly, many staff felt a greater sense of ownership over the content and were motivated to improve the quality.
This also provided a very useful framework to build from. Automated scripts (such as spell checkers or broken link warnings) could be run when the edit page loaded, as the staff member typed, or when saving the page.
Due to our time constraints, this was rolled out incrementally. Our first release could not upload images and could only edit existing pages. Gradually we continued to add and improve features. Even when “feature complete”, there are limits on what we could do when only editing a single page in isolation.
Building a bespoke tool like this was probably not the right solution. For the same amount of effort we could have installed and customized a fully featured CRM, which would have been feature-complete from launch. Using mature software would also have given us useful features that weren’t high priority enough to justify the time needed to build them from scratch.
At the end of the day, we’d put a lot of effort into rebuilding the key features of software that was already available – open source and free – for us to use. That seems crazy.
We’d kept our website as flat HTML pages. We hadn’t made any structural changes that might interfere with the Web Team’s larger project planning, and hadn’t built anything the staff would consider to be a CRM or would directly compare to the Web Team’s final CRM project. Workplace politics had been sidestepped, and the Web Team felt supported rather than undermined. We’d made our own lives easier, while giving hundreds of staff members the ability to comfortably build and edit webpages. Engagement with the website – both building it, but also visiting it for this content – skyrocketed.
Ultimately, we were able to continue providing the quality of service we had always provided, without stretching ourselves thin from the extra demand. We’d also freed enough of our work hours to start working on the next project.