GTwM's project approach

Although most of our team have roots in IT and software development over the past 8 years we have been continually refining our approach to starting and running a project, simply because IT and change go hand in hand. Projects can rapidly become very hostile environments, however it does not have to move in this direction. We believe the way one approaches change is probably the most important part of any IT (or other) project so we have recorded our thinking / experience in this area.

Background Research.

Looking up publicly available information about the organisation is only a start . Ensure early client interactions really flesh this research out;

1. core group theory can be helpful to inform your search for key decisionmakers in the organisation. What has driven this core group / organisation in the past? Static or falling sales / missed opportunities / potential bankruptcy / crippling costs etc. are likely to be the sort of factors that will ensure a project gains momentum. (Feel the pain OR see the gain!)
2. garbage can theory can help inform the search for any organisational history that might underpin their current understanding and future positions. Very few projects start with a blank sheet of paper so what is in the organisations project portfolio? What details can you garner about projects that have been undertaken or mouthballed in the past?
3. Who were the contractors involved in these projects? What was the balance of success / failure and what lessons have been learnt? What is the organisational history re reuse / make / buy decisions?
4. assumption based planning can be used to help unearth & test any "solutions" brought forward from the above
5. try to understand the organsational structure and where they might sit on Grieners model, look also at Mintzberg's more detailed work on the relationship between Structure, the Environment and Leadership styles. Use this to anticipate the likely balance between formal and informal process orientation within the organisation.
6. remember Mintzberg's arguement that most published / formal information re an organisation tends to overstate the level of control management has exerted over the strategic direction it has taken. Be sure to look for additional drivers (external and bottom up) that have in the past contributed to the formation of emergent patterns. (Tracking Strategies, 2007)
7. research the management control systems that are currently in place, combine this with your understanding of their structure to see if there are any missing or problematic control systems that might constrain the project etc.

Go / No Go

Assimilate this research to help evaluate whether this is the right time for / kind of change initiative. (See Enterprise Architecture) If the answer is yes, no problem, if no - you have a personal decision to make!  Assuming the decision is to go ahead don't forget to agree Risk Management  approach. Then follow Kotter's approach to managing change.

1. Step 1 of Kotter's approach to Change Management is to "create a sense of urgency".  (After the project has been authorised we have found focusing on Project Failure and the most Common Project Issues equally useful in maintaining urgency at the project team level).
2. Step 2 of Kotter's approach - "build a guiding coalition". Using the knowledge you have gained from your original research about core group members try introducing Stakeholder Analysis & Management techniques. Step 1 should help you avoid being side swiped by decisions handed down by powerful members from outside of the coalition. The aim of Step 2 is to help ensure the differing needs of core group members are balanced enough to create a viable coalition.
   
3. Step 3 - "create a shared vision". High level "scene setting" discussions about resource allocation / redistribution will be a key issue and at this point it can sometimes make sense to use the Boston Matrix or  build a strategy canvas following the theroy found in Blue Ocean Strategy. Maybe also use the TOC framework explained in detail in the document Toc And Resistance To Change in the Learning Resource table in GTpB to clarify thinking.

Kotter's approach can be very "top down" so we believe in adding a further step - "situational analysis" which is in effect a second more detailed reality check to see if the client is ready and able at the operational level to execute their vision. How big is the gap between current & future desired state? Image:PM Maturity Questionnairev3.doc? How aligned are the staff? Are the staff free and able to help out?

Situational Analysis

1. Learning: Skills audit, requirement, gap analysis. (See Learning Organisation)
2. Business Philosophy: What is the predominant philopsophy? Is it aligned with the toolset / methods? How widely understood / shared? See Strategy, Top Down, Lean, Hot Groups
3. Infrastructure: Is the structure able to support the project / change? See also Organisational Lifecycle , Levers of Control , Levers of Organisational Design etc One interesting question here is how would you classify the software applications that exist within the organisations. Would you call MS Word a tool? and if so is an ERP sys also a tool or part of the infrastructure?
   
4. Tools: A common "team toolset" to cover the planning & implementation phases of any project is essential. However we also believe there is a need for a "team toolset" to underpin the "checking" phase (see PDCA) of a project, a toolset that reflects the specific nature of the project. For example a simple e-Commerce project toolset might include a variety of Web Analytic tools such as Marketing Manager, Site Stats, Google Analytics, EbAY Email Sales Reports Plus etc. Alongside generic reporting tools integrated into databases.
   
5. Methods: For simple projects a standard Waterfall approach will probably work however for more complex problems we have found the Agile approach more succesful. We have always ruled out Selectivism as an approach in the belief that clients would reject it on grounds of cost (even though it has proved very effective for Toyota). Prince2 can help.
   
6. Individual learning (Who might benefit from going on a course or at a minimum being made aware of certain methods and maybe given pointers about further reading etc)
   

From here on in we follow Kotter's approach to it's conclusion starting with "Communicate" like mad. We  often borrow visual management from Lean Production , and Process Mapping maybe even add a slimline Balanced Scorecard . We are trying this approach at the mo with a varied range of projects. Can't wait to see how they pan out!

Projects

Castell Howell Foods

Over the last six years we have worked with Castell Howell Foods Ltd,

• building rapid prototype systems to complement their core ERP system
• e-marketing developments across a range of projects

wikiBase

We have also developed wikiBase, a database (portalBase) and communications (wiki) product which clients use to rapidly develop web based applications, for a wide range of needs including

• project management
  
• CRM
  
• metrics tracking
  
• issue tracking etc.
  

Gorseinon College

GT webMarque have worked with Gorseinon College for three years during which time they have helped them

• adopt the GT trainTrack product to manage their work based learning
• advised the College on the management of their Welsh Lifelong Learning (LLWR) data.

Sporttrain Wales Ltd

GT webMarque worked with Sporttrain for three years during which time they:

• developed the GT trainTrack MIS product
• developed a quality system incl. approx 600 process maps 
  
• ran a compliance project to ensure funding was sustained

trainTrack

GT trainTrack is a sector-specific product that GT webMarque developed for a number of Welsh learning providers to track learners and collect funding for Work Based Learning courses.

Company working resources