Successful Projects
It’s a painful reality that projects frequently fail to achieve all the expectations set for them, and in some cases fail entirely. In this article we will take a look at some of the issues but our focus is very much on how to set up and manage projects successfully.
In this article we’re also going to save you a lot of time as if you type ‘project failure’ as a search on Google it will return 137,000,000 responses and for ‘Project Success’ 308,000,000 responses. To keep things simple we provided our overview under the following headings:
- What is a project
- Project Outcomes
- Plan
- Budget
What is a project?
If you ask your IT team or supplier to explain what a project is it’s highly likely you will get several different definitions and various references to Prince2, APM and PMI. Project Managers are no different from technical specialists in using a lot of jargon, which can be both confusing and result in a mismatch in expectations
At Korolit we have a solid track record of providing guidance on and delivering all types and sizes of projects from small changes through to large complex global programmes, including Project Management Office (PMO) set-up and management. In our experience all projects share the same basic characteristics:
Projects comprise outcome, schedule and budget
- Outcome – Something will be introduced or change
- Plan – It needs to be done in defined way and by a set date/time
- Budget – There is a defined cost to deliver the outcome
To be successful you need to have clearly defined, agreed and managed all of the above elements.
Project Outcomes
Outcome is a term that most IT departments and project managers rarely use as they generally prefer to use the term objective. Take a look in your dictionary at the definition for objective and you will find a lot of text but not much clarity, it can mean many things. In sharp contrast ‘Outcome’ is defined in the Oxford dictionary as ‘the way a thing turns out’ and we think this provides a much better foundation for ensuring you end up with the result that you wanted.
We would strongly advise you to invest some effort in thinking through what you want to end up with and how you will be able to test or confirm that it meets all your expectations. In many cases the IT component of any project can be relatively small compared to the people changes. By way of example putting in a new phone system may require a bit of technical expertise but in most companies the bulk of the work will involve:
- Understanding how the existing system is being used?
- Types of usage (e.g. reception, office, management, call centre, guest etc.) and their specific requirements?
- What new features does the system have and will it affect the above?
- How will you train the above groups to use the system effectively, will you use the technical staff or a specialised trainer?
In the above example one outcome might be to confirm that each type of user (e.g. reception) has both a comprehensive training programme, handover and that going forward there is a training pack that can be used for new starters and people changing roles.
Many projects fail because they start to incorporate additional requirements after they have started, or are too big at the start to be delivered in one change. We would advise you think ‘big picture’ with outcomes. Consider overall what you want to end up with and not just a specific change. This will help you to scope a change and manage expectations for both what it will and will not deliver. This may then encourage you to break larger changes into separate discrete projects that can be delivered and more effectively absorbed by the business based on priority and dependencies.
With that earlier phone example you might be keen to both get a better service and introduce a Call Centre into your business. Rather than trying to cope with all that change in one go you might decide to do this as an overall programme of change comprised of two projects with a pause:
Breaking up a larger project into smaller deliveries
In project 1 you will probably need to include the functionality for the Call Centre but it would only be made active in project 2 which would include all the other changes (e.g. recruitment, staff training and HR changes) to introduce the Call Centre. The pause after the first project allows time for the system to bed-in and any problems to be resolved. It also allows you time to build a base of skilled users and this will make project 2 a lot easier!
Plan
There are many ways to organize a project but we believe that all follow the same overall approach:
- Discover – Outcomes are clear and agreed along with the project organization, plans and budgets
- Design – A clear definition of what is going to be delivered and how it needs to work with existing and planned systems
- Deliver – The work to deliver and manage the change along with its completion and ‘handover’ to the teams and people who will use and maintain it.
Assuming you have followed our guidance on outcomes the scope of the work should be clear along with any dependencies on earlier work. This will make it much easier to plan the work and manage any minor changes, risks and issues. It is important to fully understand the budgets for the work and we include this as an additional section below.
The plans will clearly show what work will be done, by who, when and how it will be verified and signed-off at all stages. The project organization needs to be defined in terms of who needs to be involved to ensure the success of the work both in terms of the IT and business.
The design of the change must clearly show how it will look from the outside looking in and your technical team will refer to this as the ‘External Design’. Essentially this shows what the system needs to work with (e.g. the HR people system might need to populate and maintain the phone system directory). The way the system will work is defined in a document called the ‘Internal Design’ and this is usually the highly technical bit that explains how the systems will do its job.
The technical team will test that the internal design does its job correctly during delivery. You will also need to work with the project team to agree both the external design against your agreed outcomes and what tests are required to prove that the system behaves as expected.
A key part of the delivery work is to ensure that the change or new system can be used as agreed and maintained after it has been implemented and these tasks are included under the general title of ‘Handover’.
Budget
Probably one of the most overlooked elements of any project is budget. Most Project Manager will add up all the costs of buying any technology required, their time and the technical resources required and present a budget for agreement. These costs rarely include:
- Contingency
- Non-IT related costs
With the best intentions on all sides surprises do happen, a new bit of technology might need a slight change to make it work correctly or you might request a small change to an existing requirement. It saves a lot of irritation and embarrassment at a later stage if these risks are considered at the start and an agreement is reached on the level of contingency that should be included in the project budget.
Most if not all IT projects require assistance from non-IT users to complete the project. Going back to the phone system example there might be a cost for staff to come in out of hours to test the new system. These non-IT costs should be included in the overall project scope, schedule and budgets.
Conclusion
The Egyptians were project managing as far back as 2,700BC so the practices are very well established. Essentially we have no excuse for failure!
Where we do go wrong is by over-complicating the process and losing sight of the important elements. Think in terms of outcomes, schedules and budgets and you will be on the right track. Spend more time considering what it is that you actually want to end up with, not just in respect of a specific change but overall, and you will have a better start point for scoping out what the project will deliver. This will hopefully avoid later requirements change and scope creep!
Bear in mind that the IT element of a project actually represents a relatively small component of the change compared to the business changes required and include this in your schedule. This then also forces you to engage the right people on your team. This also applies to budgets and don’t ignore the importance of considering contingency as things do go wrong and things do get missed!
At Korolit we have a lot of experience and expertise in successful project delivery and can help you in the following ways:
- Guidance and coaching on scoping and running successful projects and project delivery organisations, including Project/Programme Management Office (PMO) set-up and management
- Managing work for you
- Auditing existing projects where there are issues or perceived risks
- Helping you to build your own team including recruitment
- Contact us to find out more at www.korolit.com.
anthonykking
We’re an independent and experienced consulting, programme management and executive resourcing business. We're focused on the needs of both public and private sector clients. We work with all sizes of organisations from local start-ups through to global concerns. Without the cost overheads associated with a much larger consultancy business we have the flexibility to take on small targeted assignments, or much larger work programmes. Every client relationship is valued greatly and treated with dignity and respect. Each engagement benefits from the breadth and depth of our expertise.
