How I Delivered an Architecture Streamlining Project

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.