Use Teams to Their Strengths
Formulate a Robust Strategy
Identify Areas Where Problems Might Arise
Delivering the project
In this post I want to talk about a project I
delivered. I want to highlight the challenges
I faced, how I formulated my strategy, and how I coordinated my team to
successfully deliver the project on time and on budget.
My hope is that it may help you with your future projects.
 |
| Using Tuckman's model I got the best out of my team |
The Brief
To formulate a strategy and solution to replace/upgrade
applications, servers, clients, contracts, licenses, business impact analysis,
business continuity plans, while maintaining the IT infrastructure and
architecture within the organisation, minimising downtime and ensuring
replacements/upgrades were up to task.
Where possible, the replacements/upgrades would have lower maintenance
costs and downtime. The replacements
have to comply with country specific laws and regularities as ISO27001.
Assessment
The scope of the project was large. The organisation had business applications,
servers and clients running different and aged operating systems and
applications. Windows NT, Windows 2000,
Windows 2003, Windows XP, and Windows 2008 were all in operation. Most needed to be replaced and/or
upgraded.
Strategy
I decided that to meet the project deadline, I split my team
into two, allocating sites to them respectively. I felt this would speed up the project as the
deadline was tight. I was also
determined to stay within budget, and I knew time would be a factor in
that.
The personnel in the team were chosen to compliment their
strengths and weaknesses. I ensured
that they had natural project leaders, and I made them responsible for their
team’s performance. This provided me
with one point of contact for each team.
After the teams were finalised I gave each team leader the
following brief:
·
Take an inventory, rationalize and capture the
following data:
Ø
Usage statistics including trends, capacity,
performance, and growth since inception.
Ø
All
applications and services running on the clients and servers. This included usage within the organisation,
business process maps, ownership and agents.
Ø
All data connections between applications,
specifically middleware and interfaces.
Ø
A list of all SLA, licences, and contract
requirements.
Ø
Business impact analysis, business continuity
plans and disaster recovery plans.
Once this was complete on all sites I then decided to
conduct a Product Risk Analysis. Although a lot of the architecture and
infrastructure was going to be made redundant, a fair amount was going to be
retained. The aim of the analysis was to
grade the amount of testing required and the amount of redundancy. At this point I factored in security
requirements outlined in the brief.
After discussions with my teams I identified:
·
The applications and services which required
upgrading and the minimum technical specifications the replacements needed
·
Pinpointed the (business) applications, clients,
servers to be retired
·
Mapped (business) applications dependencies to
servers
·
With input from my teams we ensured the
replacements/upgrades would meet SLAs, law, regularity and security
requirements
·
Gap analyses, business and disaster recovery
plans
From this point we had a clear path or at least a clearer
path. Although we had made good progress
so far I wanted to bring in the next phases faster, as I knew bringing new
architecture online and testing was going to be stressful.
At this point I assigned the following to my teams:
applications, data, infrastructure, contracts & licenses and business
continuity, as we knew this would be stressful as we carried out the following:
·
Local
Consolidation of applications (incl. data(bases) based on standards and
policies
·
Global
Consolidation of applications and hardware standards and policies
·
Architecture
work to define the new architecture and infrastructure, taking into account
redundancy requirements etc.
·
Create
test scripts for the SIT, UAT and PAT testing of the new IT landscape
·
Rework
SLA and contract requirements.
Execution
Once I was satisfied we were ready for the next phase, we
began to transfer users to the new environment, and integrate the architecture
we were keeping with the new information systems. I assigned teams to handle the transition and
I kept a vigilant overview. I decided that we would integrate the business
processes and supporting departments one at a time so we could monitor and address
issues.
We scheduled the transition at a convenient time. I negotiated this throughout the
organisation, liaising with departmental managers and (international)
leadership team.
The migration went extremely well and was able to address
issues before they became problems.
Overall the project went smoothly and I delivered it on time
and on budget. My teams were exceptional
and many of the complications I foresaw never materialised thanks to our
planning and execution and a hawk eye on project teams development during all
stages.
To get the team to perform I followed the recognisable
stages of “forming,
storming, norming, and performing." Psychologist Bruce Tuckman, who
created this memorable phrase, later added a fifth stage,
"adjourning" or "mourning."
My advice
is to use Tuckman's model to help your team reach the performing stage as
quickly as possible. First you identify the stage of development that your team
is at. Then, you use strategies that move your team through to the next stage
in the team formation process. With focus and hard work, you'll quickly have a
high-performing team.
This was
invaluable for this project.
