— 12 August 2004 —

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.

Respond Eloquently Below

April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002
Snook Approved!