Portfolio – Enterprise Change Management

This is a Web application to create, edit and manage a knowledge base for different organizational change categories. The design is proprietary. Please ask to see a scrubbed screenshot.

Project History

I was lucky to join this project at its inception. The team was rather small, which is unusual, but everyone was receptive to my explanation of what I do. So much so, the Project Manager asked the team to follow the user-centered design methodology, and only follow the regular development methodology for required deliverables.

The other somewhat strange aspect of this project is that there weren’t any users, current or future. The answer I received as to users was: it could be anyone in the company. Which is the stock answer when someone is building an application they hope people will use, but haven’t actually defined a user group yet. The only users we did know about was the 5 person team that would be administering the knowledge base and the application.

And (okay last strange thing I promise) the other strange thing was that the project team was staffed by the same people who would be administering the tool. Yes, this might be considered foreshadowing.

This was not a large application; only 30 screens. But I again took the opportunity to explain about CSS and its ease in management of the look & feel of the UI. A branding initiative was underway in their area so completely redesigning the UI was in scope.

Success Factors

The fact that the group was small was good in a number of ways. Decisions came quickly. There weren’t many people from whom an opinion had to be gathered. Also, because of the support I received from the PM, I was in charge. A mini-PM if you will. From a professional development standpoint, I had a lot of opportunity to work on leadership and communication.

I was able to teach most of the team members the value of user-centered design, and get feedback from them that they believed in it. Before my arrival, most of them fell into the “I think it should work this way” camp. What I was able to do was assist a mind shift of about 8 people to think more about the end user, and not focus solely on the system. This shift allowed me to focus more on my tasks than negotiating the time and hours to do my tasks.

Things That Could Have Gone Better

Foreshadowing payoff. Having the people who administer the existing tool also be the business and systems analysts is not always a recipe for success. It can work, but I have found that working with teams that don’t understand the difference between ownership and responsibility gets in the way of actually success. As such, we had a team of owners and egos continuously got in the way, as opposed to a team that is responsible for the maintenance of an application.

Egos were easily upset on their side and this led to many very unhelpful meetings. Luckily for me and my work, I was able to talk to both sides of the table and get buy in on most issues generally revolving around requirements.

The second part was the biggest factor to the hit to the timeline. The business partners and the SMEs really thought they understood the requirements. They did, but they each had their own individual understanding. Requirements were written down, but not well detailed and there was disparity in meaning.

What I Will Do Differently Next Time

One thing I learned from this project is to meet with the sponsors early and often. It is not enough to meet with the PM and the project team, and possibly the sponsors at the beginning of the project. Generally I only meet with the sponsors once and it is enough, but with more and more development crossing fiefdom lines it is imperative to get agreement at the highest level of project administration: the ones with the checkbooks.

Another “next time” idea is to get everything in writing. There were a lot of verbal agreements on this project and I let many of them stay verbal out of trust. In the end it’s not about trust, but about getting public agreement on all major decisions. This goes beyond requirements documentation and UI specs. It’s all the meetings and the meetings after the meeting where most of the decisions are made.