ATTENTION: WiBit.Net will be temporarily taken offline for routine maintenance on 9/22/2018. The site is expected to be down for 2-3 hours.
We apologize for any inconvenience.
WiBit.Net Blog (48)

 Kotter's Model of Change for a Software Architect

Thu May 26, 2011 1254 views
bryan

Kotter's Model of Change for a Software Architect

A good software architect is almost impossible to find as they comprise of 1 part senior developer, 1 part visionary, and 1 part salesperson.

Often times a developer is promoted to this position without the support of management and simply continues as a tech lead instead of a true architect. Other times this position is filled externally, where someone comes pre-programmed on how things were done at ‘fill-in-the-blank’, tries to dictate the new methodology only to be met with intense rebellion from senior developers.

Overcome Resistance
The first phase of getting a change or project kicked off is by simply overcoming resistance to the resulting change. This can be achieved in three simple steps.

1. Capitalize on Concern
Those in any position of value will be accustomed to the daily noise of concern from both ends of the organizational spectrum. Whether these are concerns resulting from a specific incident or an upcoming deadline, you can use this knowledge to kick-off the change during an environment of urgency.

2. Pick the Best
I can’t put this more simply, choose the best you can. Always. It’s a team that succeeds, not a rockstar. Part of getting people to agree is to have a likable personality and to advocate projects and change that are truly beneficial to everyone in the organization.

3. Set a Clear Vision!
This is the most important step in overcoming resistance. When a clear vision is not set, the team members may get bogged down in creating actionable items to produce and conflicting visions of the outcome may grow. Your job is to make sure that we are all looking to take the same hill and are marching in step with the same clear goal in mind. This is accomplished by preemptively creating clear and well organized requirements both at a high and detailed level.

Implement and Sustain
Now that you are prepared and ready, it’s time to move into the executing phase by implementing the project or change.

4. Get Sign Off
The quickest way for a project to fail or for a change to come to a screeching halt, is by a higher up pulling the 'unapproved’ card. Once that happens, it’s a quick game over. Have your sales pitch prepared and take it to either management, a change management council, or steering committee. One way or another, make sure you knock the pitch out of the park and seal the deal.

5. Breakdown Project and Submit Requests
Most people required to complete a project won’t be active participants. They will tend to be 'queue based’ workers and focus simply on pending requests they need to complete sorted by date due. It will be your job to break the project into smallest possible physical actions and submit each of them as formal requests will clear criteria for judging success and a specific due date. This way, each of those requests will be processed in the queue of the employee required to do the task and you can track progress. Most companies will have a system for submitting and tracking requests.

6. Celebrate Short Term Wins
Now that the project has been broken down into small parts, there will be little obstacles and successes. Make sure to celebrate the short term wins as much as possible. This keeps everyone motivated, valued, and interested in the success of the larger project or change.

Integrate into the Organization
Sustaining the change is just as important as enacting the change. If the project is complete but not supported by the organization, it will be considered a risk and unsustainable. The easiest way to deal with something that is risky and unsustainable is to sunset the change or project. We don’t want that to happen. It is now time to integrate what we have built into the organization.

7. Never Let Up
Once the project is complete, find ways of documenting each persons role required to support the change and communicate this requirement as a duty of that position. Make sure this documentation is in the new employee intake workflow as well.

8. Make Sure to hit Deadlines
You must hit deadlines so that resources can be reallocated back to their 'natural’ duties. This will not only help you to persuade upper management to sign off on the next project but also to transition people into a support role for the completed and lasting change.

Now go out there and get things done.

–Bryan

Health and Development... Like Oil and Water

It is no secret that software developers spend a lot of time on their asses.

Visual Basic: It's called BASIC for a reason

Over our years as software developers we have grown a distaste for the language Visual Basic.