Don't go Changing to try and Please me..
Yesterday I spoke at CeBIT North America and did two sessions: "Patching the holes in the Change Management Process" and "Extreme XML-Interoperability in Action".
This got me to talking with attendees about my favorite topics on change management, EMBRACING CHANGE. Way too many developers fight it, hate it and die by it. I have seen whole applications die over fighting change. Let's face it: CHANGE IS PART OF DEVELOPMENT.
At Zagat we embarked on a new initiative to build the company a new electronic on-line editorial systems. The old way of doing things was 100% paper based. So this was a radical change for the business. The business had no clue what they wanted, nor was the changing competitive landscape clear. So change was going to be a part of this system in a major way. But time to market was very important since we were preparing for an Initial Public Offering (IPO).
I told my lead architect that when he was designing version 1.0 of the "CMS" or Content Management System, that I will not evaluate him by how cool Version 1.0 is or how 1.0 is accepted by the business. I will evaluate him by how fast 2.0 is built on top of 1.0's base architecture. Now that was a challenge. Designing a system for change in the first place! This affected the entire culture about change management. Change was embraced.
But how to control it you may ask? A typical project gets at least a 25% change in requirements during development. Also, a typical project tends to experience a 1%-2% growth in requirements per month-so the longer your project takes, the more change you will have to endure in the way of new requirements.
Now that being said, sometimes you have to be a hard nose on change requests. Shipping is a feature. So how do you strike the delicate balance? That is the million dollar question. (And on some projects the cost is higher.) The answer is all about BUY IN. Get the business aligned with the change culture. Set up a change control board with stakeholders from all over the business. Some of the methods of change control are:
Allow changes that help to produce the best possible product in the time available. Disallow all other changes, even if budget permits.
Allow all affected parties to assess the schedule, resource, and product impacts of the change.
All change requests, assessments and re-estimations must be public.
Get agreement from Business and Development Team on the New Delivery Schedule and Build Plan.
Now the last bullet is most important. After you decide on a major change and alter the schedule by a month, under no circumstances do you say Ok the schedule slips back a month No no no. Bad the word slip in reference to change, slips are when people miss a deadline. When you schedule a change, you are realigning your schedule based on new business reality. Do not perceive this a slip or late. It is a trade off or a compromise. Trust me, this one little thing, changing your attitude on change can change your life! (pun intended)
Give it a try and let me know how it goes.