Our special guest was Albert Quraishi, who is the RED Sky program manager in Vodafone Hungary from Virtusa, who shared his thoughts and experiences about “the role of PMO and Agile methodology in large scale IT programs – and how things can go wrong”. The moderator of the event was Julianna Czifra, program manager also from Vodafone Hungary.
Albert has 40 years experience in IT and project management. He first used a computer in 1973 at age 15 which was an ICL 1900 series mainframe. He first managed a project with his second employer Robert Horne Computer Services which was a batch Bureau house. The project was to develop an application product for the legal profession which was very successful and still is sold to this day. Since 1980, he’s been managing project and programs which means 36 years of project management experiences. The first multi-national project he did for McDonnel Douglas in 1983 which was in 3 countries (USA, Italy and UK). The project was to develop a product to manage extremely large projects over very long timescales. That product is still being used by the RAF today.
Albert gave an outlook of the IT world in the 80’s, 90’s and year 2000s in the UK, based on his experiences:
- He moved from weapon industry to IT, due to moral concerns.
- IT projects were hardware rather than software driven, with focus on DESIGN and system coding. End product was requested and delivered to a single client, managed by Sales Account Managers.
- There was no such role as a project manager at that time (70’s and 80’s), who could have managed the end-to-end process of product development but rather the product development process from conception to delivery was owned by separate departments, managed by department heads.
- Formal project management trainings and methodologies didn’t really exist. However, we can see a parallel in today’s Agile trends and the methodology used for object oriented design in the 80’s. This was critical due to the small amount of memory and disk available. Therefore methodologies first appeared due to hardware limitations and the needs of simplifying and standardising the design process.
- With the advent of smaller more affordable computers there was a move away from external data processing outsourcing to internal computer departments.
- With the appearance of cheaper packaged solutions which were hardware platform independent (portability) e.g. Microsoft, in the second half of the 80’s there came a shift from single client product developments to standardized, off the shelf products that required customization based on customer needs. Sales focus became software package led, and a key concern of companies was to find a cheapest platform to run the software on. Software therefore became hardware independent and has remained like this ever since.
- With the advent of sales being led by software packages companies starting with database vendors, (e.g. Oracle, Sybase Ingres, etc.) instead of hardware lead. This created an opportunity for software companies to develop packaged software solutions for databases and create partnerships with the database vendors. This was the advent of the system integrator. At this time the leading management consultancies saw an opportunity to offer their management expertise to IT Projects during the 90’s and to offer methodologies and best practices in managing with implementation and customizing packaged software solutions for companies.
- These consulting companies were not technical experts, therefore they relied on system integrators (such as SAP, Oracle) to implement the solutions, while they focused on developing management approaches for the client. This was the start of the expansion of the role of Project Support office to becoming project management office (PMO).
- Certifications also appeared on the market in the 90’s to offer professional qualifications to project managers.
- From the year 2000 onwards PMOs have evolved from a primarily administrative function into a governance function without acquiring proper domain knowledge which has accounted for many of the big program failures in the UK.
- Agile is now a trend but it’s not optimal for big business transformation programs, but should be treated as a „mini waterfall” methodology for product sprints developments, when breaking down product development into smaller tasks. However, for the program itself, the waterfall methodology shall be in use to break it down into manageable milestones.
- The downsize of the above PM evolution is that no proper control mechanism has been in place to control management practices, no checks&balances on governance level to control quality of PM consulting companies. The prevailing PM methodologies didn’t put enough emphasis on project assurance at a governance level.
- The lack of a proper, independent Project Assurance in governance has resulted in the UK’s two biggest program failures in the 90’s, the Taurus project of the London Stock Exchange and the NHS patient filing system in the 2000s. A main reason of failure was the blind trust of the Client in the management practices of the consulting companies, and the consultants’ strong influence on corporate management. Since then, the British methodology, MSP & PRINCE2 has incorporated the need of having an independent Project Assurance in place on behalf of the project board.
- Another reason of the big project failures in the 90’s is that consulting companies were paid on T&M basis rather than fixed or fixed+award basis therefore programs remained open ended.
- In the prevailing methodologies there’s not enough emphasis on the importance of domain knowledge when managing big transformation programs, without which no proper program status reporting and risk assessment is possible for higher management. Combined with the lack of an independent Project Assurance, management can be easily misled regarding the proper status of the program.
- Solution: Independent Project Assurance must be part of project governance, representing the Sponsor’s (Client’s) interests therefore it shall be the accountability of the project sponsor to ensure that such a checks&balances function exist within the program.
Albert also answered the questions emerged during the presentation:
- Be credible. If there’s a project you know it will fail, you have to tell the client that it won’t work or at least you won’t participate in. You must not cheat yourself or the others (stakeholders).
- You can apply agile methodology in certain projects. Agile can be used when there are lot of small pieces in the project with little time frames or deadlines or for example in case of producing prototypes. Agile cannot be applied in large scale projects like business or process transformation / development projects.
- As a project manager or project assurance professional you have to be vigilant and keep your eyes open – to have always proper information about how your project performs and what the critical factors, tasks you have to concentrate on.
- It’s important to have a methodology. Methodology is good, but it’s not enough. The most important thing is how you apply it in your projects.
In the name of PMI Budapest Hungarian Chapter we would like to thank Albert for coming and sharing his thoughts,
and Julianna for moderating the conversation in PMPub!
We would like to remind you that the next PMPub will be in February, 2017
and the Art Of Projects 2016 conference will be on 10th November!
