MassWIT Executive Women Roundtable

November 2009 Volume II Issue 3  
HOME
MassWIT Events
Wine tasting celebration next week
Professional Development Workshops
Women & Leadership
ChickChat Radio is girls' night out, every day of the week
Retaining high potential employees
Networking how-to hits the book stands
Old Girls' Network – a must-read in August
WorkLife Balance
Feeling proud
Illuminate the darkness
The Have-Do-Be phenomenon – Is this how you want to live?
Marketing Corner
Concrete content - the foundation for a professional Web site
Tech Talk
Managing change in the tech world
TELL A FRIEND:
ARCHIVE
June final notice
June 2, 2003
Vol. 1 Issue 7
Volume II Issue 2
March 7, 2003
Vol. 2 Issue 2
Volume II Issue 1
December 20, 2002
Vol. II Issue 1
Issue 2
November 22, 2002
Vol. 1 Issue 2
Issue 1
April 12, 2002
Vol. 1 Issue 1
Managing change in the tech world


In the current business environment, information technology and software programs change with lightning speed, and projects to develop/deploy them are becoming increasingly complex. How does one manage the product, the team and, potentially, the client, in this environment?

Julia Austin
Julia Austin

Julia Austin, an experienced technical organization leader in the high-tech industry, explains how she makes sense in the midst of chaos.

Ms. Austin spent the last 13 years managing teams responsible for developing and implementing software systems. Her career includes time at a Big Six accounting firm, an information technology organization supporting systems in the medical field and, most recently, serving as VP of engineering at a start-up software company.

I was responsible for change with a major impact was implementing PeopleSoft at a major health care company in the mid '90s. The most important lesson I carried with me was to be up-front and realistic about what it would take to get something done, even if the facts were ugly. Executive sponsors, management and clients were far more supportive when you set the right expectations vs. telling a happy story and coming back later to tell them you needed more time, money, etc.Illuminating risks and clearly explaining how/if each risk can be managed is as important as making sure your project supporters are signed up to take on that risk.

I found, over time, that I could manage risks quite well by building in compensating controls and by constantly keeping my project supporters aware of the project status. With constant communication and a clear understanding of how I was managing the risk, they continued to be supportive of my team and me.

There were so many factors affecting the success of the project – here is a quick run-down of the top components.

The main challenge was creating the best possible team.

We needed technical, analytical and business-savvy people on the team and each had to be able to work somewhat independently and with the team if we were to be successful. We also didn't always get to choose whom we wanted on the team. In the case of the business folks, we needed subject matter experts (SMEs), but departments in the organization who were supposed to ante up a resource for 12-18 months were, understandably, not always willing to give us their most knowledgeable resource. It was a difficult trade-off to have your best person making sure the pending change was done in the best interest of your functional organization, yet knowing your organization would feel the pain of the person being unavailable for a long period of time.
Further, the resources themselves had to be willing to change roles for a year or more and would need to be willing to take on the added responsibility of being the change-maker.
What if the project didn't go well? Would this individual have a job to go back to?
Even after we got the team together, corporate strategy changes, reorganizations, attrition and other chaos made keeping an even keel and the right people on the team a challenge.

In addition, we had consultants from both boutique and large firms on the team. Integrating each firm's proprietary methodology, culture and style with our own was very complex. Also, it was important for the consultants to become part of the team, such that the overall project team was cohesive and could build momentum to meet aggressive timelines.

How did we overcome it? Several success factors came into play.

Communication. We did our best to clearly communicate to stakeholders that giving us their best (and letting us keep them on the team through the implementation) was in their best interest for their expected result from the project. We had to exemplify how their staff made a positive difference on the team and we clearly identified what would not happen if they were taken off the team.
For the SMEs, I did my best to assure them that I held myself accountable for their success in this new role and would back them in any way necessary to help them implement the change and reintegrate with their teams post-implementation.
For the consultants, we eliminated project manager/lead roles offered to us by their firms. We took their best folks and said, "Forget who you work for while you're on this engagement, you are part of our team and a welcome addition!"

Project management. It was an ongoing effort to make sure we were estimating the right time to execute each phase of the project and we were constantly rechecking against major milestones. Also, it was a creative process to line up many parallel activities and have them all meet a major milestone at once.
For example, we had to make sure the new accounts payable (AP) system was ready to test at the same time the new process for AP was defined and at the same time the check-printing system was also ready to test. With other modules being implemented, several legacy systems to replace and tens of thousands of invoices that had to continue to get paid throughout the project lifecycle, it was complicated! Concurrent activities included software development, database design and performance tuning, process analysis and design, SME reviews, feature prioritization, etc. I managed all this activity with weekly status reports from each of the teams, bug reviews, process reviews, team checkpoints and tons and tons of day-to-day communication. The teams were encouraged to bring any new hurdle to the attention of the project team leads so we were always aware of a potential hit to the schedule or budget. No one was reprimanded for slippage unless there was a clear-cut reason for it and the whole team took it personally if we failed in any way. No one wanted to see the team fail and the momentum of everyone shooting for perfection saw us through many potential failures that were resolved well in advance of our project deadlines.

Sponsorship. I had a project sponsors team that was made up of major stakeholders (VP-level) across the institution. Other project leaders working on the overall initiative and I would present a project status to them monthly. The status would include milestones met, potential or current slippage and why, project risks and how we were managing them, and then a short-list of items we needed their help with. Examples of help items include additional budget for an unexpected hardware purchase or maybe approval for a bonus program to mitigate staff attrition.
In addition to these reviews, the sponsors represented the project at executive meetings, which was critical. We counted on them to block and tackle the politics associated with this major project and to set a good tone across the organization so we would succeed upon rollout.

Motivation and teamwork. Pride for the project was key. It started with the team first giving the project a name so the team could identify themselves as a group. Then, it was a matter of organizing the team in a way that people felt good about the role they played, and enjoyed who they were working with.
This was evolutionary, as team members changed and relationships didn't always work out. We often took the team out to "play," typically to celebrate milestones, and we planned meetings and outings around consultant's Monday-through-Thursday schedules so they were always available to join as part of the team.
Focusing all successes and failures on the team instead of individuals was important as well. If a bug wasn't caught in testing, it was the team's fault for not making sure someone tested for the bug and not an individual.
Team accountability was important. Likewise, team leaders were responsible for setting the tone of their teams. It was very important that the team felt good about what they were doing.
Often the work was less-than glamorous, but it had to get done. I made sure the teams appreciated that everyone had to do the mundane stuff at some point along the project and that there were more glamorous parts of the project coming. Further, people were recognized broadly for completing even the most mundane of project tasks. You can never send out too many "kudos!" e-mails!

We ensured that the project leaders gave it their all: All team leaders, including me, worked just as hard as the team. Putting in long hours, volunteering for grunge work like data cleanup helped motivate the team. In the end, once we had completed the major parts of the implementation, we had a big bash and gave every member of the team – about 50 people, including the executive sponsors – an award that was related in some way to the role they played on the team.

It was a lot of fun and brought closure to a long and hard effort that was extremely successful!

Look for the next issue and Hilary Coolidge's second part, entitled "Q&A on managing change successfully."


[PRINTER FRIENDLY VERSION]
Powered by iMakeNews.com