I vividly remember my first big project and the heavy responsibility the words ‘delivery’ and ‘project management’ impressed on me when, fresh into a new job, I had been assigned a high visibility project, sharply moving from a business analyst role to a blended business analyst / project manager role. It is fair to say, my first experience of project management wasn’t the smoothest, but being the determined and ‘nothing will beat me’ type of person I was stubborn enough to dig deep, learn on the job and deliver one of the most challenging projects I’ve had to deliver in my early career.
The budget was tight, and I agonised over it for days, going back to the team of developers I was working with over and over to ‘trim’ it down, make it fit but don’t lose on quality or expectation of delivered functionality. I vividly remember the conversations we had within the team and with the customer about the expectations, budget, requirements and phasing of delivery. One of the challenges I had as project manager (and no doubt this will resonate with a lot of my fellow project managers) was building of the team, gaining the trust of the customer and moulding both the customer team and the IT team into ONE team, with common goals, but mostly building a team that trusted, respected and supported each other through the ups and downs of the project.
I also remember the thrill when that first project was completed – successfully – 3 years down the line, at the end of the third phase, when the solution we designed, built and implemented went global. I remember how proud I was when the teams’ success (the ones that were still with the business by end of the third phase) had been recognised with an internal award for Project Delivery Excellence. I can honestly say that this 3 year-long project, and it’s multiple phases, was the project that defined my next steps in my career; it was the project that made me do what I do today; it was the project that ignited the desire to deliver software and bring palpable improvement to business processes.
Thinking back, first I learnt about project management were the project phases I was supposed to follow. The books were very clear about that, all the learning I’ve done, the courses I’ve followed were clear about that too. I was supposed to follow each of the stages with nice stage gate sign off. The project stages are learnt about were:
- Initiation phase
- Analysis & Design phase
- Design & Build phase
- Testing phase
- Readiness phase
- Project Review
The delivery life cycle must have defined Phases and Stage Gates:
The books and courses told me I must wrap my project in a tight Project Governance process and to ensure I handle the Change, the Risk & Issue, the Stakeholder & Assurance management processes AND, should I follow all these to the letter, we will be successful. Putting all those on paper the delivery looked straight forward.
Well… it is straight forward, but not as straight forward as the books and learnings led me to believe…
Delivering IT / Technical Projects can be challenging, with 83.9% of them partially or completely failing to deliver the desired business outcomes. Indeed, projects are, by their nature, unique and the unexpected often materialises. However, with good planning, good project management practices tailored to suit the specific project, and with the support from the right team at the right time they can be equally rewarding, delivering business success and building teams and long-lasting friendships along the way (one of my friends was my customer many years back; now she is one of my best friends, my mentor and my most trusting sounding board)
The Standish CHAOS report statistics are commonly quoted regarding the poor delivery of IT projects, whether they are custom-designed IT or bought in services. Although projects following Agile methodologies seem to fair better than those being delivered via Waterfall approaches, the risk of poor realisation of business objectives is a common to both. The projects most people remember are the ones that
- fail to deliver on time,
- fail to stay within their budget,
- fail to deliver what the business wanted,
- or, in some instances, fail so significantly they are cancelled.
I have experienced project from different positions – this article is based on my experiences with managing IT projects; working with clients, customers and business managers implementing SaaS products or designing new systems and integrations over many years. Having worked on IT projects that have not gone smoothly and on IT projects that have won awards I feel that it is worth sharing the learning and insights gained through these projects and explain why, based on these insights, I have decided to developed a flexible Project Management framework and delivery methodology adaptable to the various type of IT / Technical projects we deliver across our clients’ portfolio. I have decided to adapt my language to plain English and help my clients understand the jargon I, and the team working with me, are using, and along the way I have decided to share my experience and try to demystify the terminology in the hope of bringing value to readers of this article, but also to the clients I am, and will be, working with.
Why do I think it is worth sharing my experiences? Aside from a pragmatic view that sharing of learning is intrinsically value adding to those it is shared with, research has shown that a project success can be influenced by the competence and experience of the project manager engaged in delivering the project. I hope that by sharing my learning I am assisting with this critical success factor. Certainly, some of our past clients would perhaps feel that, had they had these pointers to reference when they first started encountering IT projects, it would have increased their confidence on what they needed to do to ensure they give their projects the best chance of delivering success; avoiding some of the ‘trial & error’ steep learning curves they experienced.
For the client business manager (who may be the CEO, senior manager, business system/product owner, the project sponsor, or a business domain expert) to ensure the project meets the business needs I aim to demystify the typical lifecycle of an IT project. Although the focus of my projects is on software development and data transformation many aspects will be relevant to any other IT projects as well.
I am sharing because:
- my experiences show that requirements are driven from within the business functions, but the delivery requires involvement of IT personnel (be it internal or contracted).
- one of the most important factors in achieving success is ensuring that the team works together and both sides of the team (business & IT) understands their roles, responsibilities and areas of influence required to ensure & assure the project delivery success.
For those of you that have been asked to take on a business project but ended up needing IT resources, how many times have you wondered what most of the words used by the IT guys mean: requirements gathering, user stories, smoke test, bugs (which are not the same as those live little things that have the bad habit to crawl everywhere no matter the weather!), and all the other jargon? How many times have you wondered what is hidden behind those words and more importantly what do they mean to you? Did you ever wonder if you do need to understand them? Or should you understand them? At the end of the day these IT people know what they are and surely, they, the IT people, are the ones that should know them. Have you ever wondered if they are just some made up words? Have you ever felt on edge that not knowing them means that you possibly many not trust all that is being said to you? Are you confident that you know what your role in an IT project is; what you’re expected to do?
If your answer to all these questions is ‘yes’, then carry on reading. This is the beginning of a set of articles set to breaking the mystery. These articles are about using plain English to help you understand all those fancy words, to give you the confidence to take full control of your project. But mainly, these articles will aim to explain the most important aspects of your involvement in an IT project; the expectations set on you, as a ‘customer’ of an IT project.
Ultimately, my aim is to take you through what you need to know, the activities you will need to participate in and own as stakeholders. Even if you are familiar with project work from within your own domain there are IT project activities, and IT jargon, of which a clear understanding of will support the interaction between you, your chosen IT project manager and the team delivering the project. Being unfamiliar with project management techniques can add another layer of complexity for those who are assigned to run or oversee a project that is an IT project.
Despite the all the stages a project should follow, to keep it as simple as possible think of the Project Life Cycle as 3 main steps:
- Business Process Analysis
- Architecture, Build & Implementation
- Customer Success
The Business Process Analysis step of the project enables you, the client, to tell your IT project manager & team about your business: what are the pain points you are trying to address, why the project is required, what is the change (and level of change) the business is expected to absorb, your timeline and ultimately the business benefits you are looking to achieve at the end of the project (short and long-term). This first step is critical because it captures the answer to the questions: Why is your business embarking on this project? What are the desired benefits this IT implementation or integration will deliver to your business?
The second part of this step is the IT teams’ opportunity to present back to you how they plan to help you achieve, via a series of workshops, meeting & calls (remembering our new remote way of working) all wrapped into a Business Process Analysis report & proposal of next phases delivery.
Acceptance of the proposal is the cue to move to the next step.
In this next step the IT Business Analysis skill sets are heavily used in defining the architecture and design, the output of which would be documented into a requirements document. And here is the starting point of the implementation and introduction to a new set of skills required in an IT project: the Developers; the Testers, the Quality Assurance Authority.
The simple diagram of the lifecycle is now enhanced with iterations that this step brings, each iteration designed to qualify at each step that the delivery is still aligned to the requirement. The assurance of the delivery is a combination of assurance process defined by each iteration combined with the quality of the delivery which each iteration quantifies. The delivery life cycle overlaid with our 3 simplified phases could be represented like this
Finally, the output of the project is your platform to success and the start of your journey to Customer Success. Note I said ‘journey’ not step! This part doesn’t have an end – your Success Journey follows the life of the product you have introduced into your business. Your Success is defined by how you nurture, grow and develop your seedling; just like a flower you’ve planted and you watch grow and flourish. Preparing your business for the change, training your users and finding the optimal way of embedding the new processes is by far the most important part of the project. Remember: even the best system in the world will not be accepted as such unless it delivers the perceived value to your end users. To some extent, the main stakeholders (and the most vocal stakeholders) of any IT project are the end users; the people that will be using the project output day in / day out. Preparing them to receive the system the right way must start at the beginning of the project and must continue long into your Journey to Success.
I hope you found this article helpful. There is more to come, such as details within each phase and linking these to the ownership of roles and responsibilities. Stay tuned!
 Standish CHAOS report
 Engelbrecht, J., Johnston, K., & Hooper, V., 2017, The Influence of Business Managers’ IT Competence on IT Project Success, International Journal of Project Management (35) 994 – 1005