Case Study from Real World Experience: The Removal of Windows Journal
Case Study: The Removal of Windows Journal
One of my last projects at Microsoft was removing Windows Journal from the operating system. There were a number of security exploits reported in the product, and due to its age and the availability of better, more secure note-taking alternatives, we made the decision to remove it.
We didn’t want to leave existing Journal users without a migration plan, so rather than simply remove it, we mapped out a schedule to introduce a “hardened” version of Journal (in this case, “hardening” meant Journal displayed open a warning dialog every time you opened a Journal note file), as well as an optional component definition for removing it manually. Our plan was to release both of these solutions at the same time so users could be secure, and have some lead time before we made the removal mandatory and permanent.
There was a problem we didn’t foresee, which became evident when we got into the release process — there is no way to both update and remove a component from Windows at the same time. A component only has a single path to follow from creation to removal. Once the component is removed, it can no longer be updated. Our plan required the component to both be removed and updated at the same time, and we couldn’t deliver on that.
So how did we solve this?
First, we recognized the problem without blaming anyone. It would have been easy to point to the project manager, or the technical lead, or the Scrum Master, in effect to lay blame. Blame does not solve the problem, but rather damages relationships and destroys team dynamics.
Second, numerous team members stepped forward to say they had missed what was, in hindsight, an obvious error. Everyone trusted the intentions of everyone else on the team, so we felt comfortable and safe accepting responsibility. Accepting responsibility still didn’t solve the problem.
Solving the problem required every member of the team to contribute to the brainstorming session to find solutions, freely and openly. Since there was trust, the discussion meant no ideas were off limits. After reviewing ideas, the solution selected was a revised release schedule which extended the project another four months.
Third, after correcting course, we communicated broadly and openly with our customers and management. Customers needed to know what to expect and when to expect it, and management needed to know what happened so they knew why we were engaged on the project for longer than originally anticipated.
In the end, the extra time was well spent, as we were able to communicate much more broadly with customers on what to expect and how to work around current issues. We were able to test and address some side-effects, and we got some kudos for our efforts.