What is IT project management?

IT project management is the controlling of processes and activities that are related to IT Projects. Projects that relate to IT infrastructure, computers and information systems are classed as IT projects. There can often be confusion between a project and an IT project so it’s important to get the distinction right. IT projects require specific skills of the Project Manager and the project team implementing the tasks. They also require different tools, documentation and methodologies to successfully deliver the project. IT Project Management includes all of the responsibilities required of traditional project management, such as managing the plan, organisation, communication to stakeholders, steering groups, and project team, whilst also being accountable for achieving the deadlines and overall goal. However, the IT Project Manager must also know about technology beyond the tools they use to manage projects. For example, an IT Project Manager who doesn’t understand system integrations, rapid technology upgrades, version changes or software testing will struggle. Without a Project Manager who understands the differences, the project will suffer many challenges. However that doesn’t mean that “being good at IT” will automatically make someone a good Project Manager. Small businesses and charities often don’t have in-house professional IT Project Managers. As a result we often see two types of Project Manager who struggle to deliver IT Projects: The Business Manager: This is a person who manages a team or a department. As a result they manage a variety of projects and are seen as the Project Manager for their department or even the organisation as a whole. They could be running projects such as management projects, research projects or strategic projects. They are good managers, thrive on multi-tasking, organising both people and tasks. They deliver time and time again. Then they’re tasked with an IT project. The aim could be implementing procured software for their department, upgrading current software or even outsourcing to/hiring developers to build their own software. But does having project management experience mean they have the technical expertise to successfully run an IT project? Unfortunately, they often don’t. The IT Manager: Unlike The Business Project Manager, this person has a sufficient level of technical knowledge but they may not have the first idea about how to run a project. They will understand the specific tasks required to implement the product/service, e.g. the intricacies of the technical specification or the environment set up. They will often be the person who keeps the entire IT infrastructure and applications ticking along with the help of a small team and/or external providers. They may seem like the right person to be responsible for an IT Project. But without business analysis skills, stakeholder management skills and knowledge of the project management processes that are needed alongside, the project will likely lack structure, planning and control which are imperative to running an IT project successfully. Therefore, in the absence of a professional IT Project Manager, one of the key success factors for your IT project is to appoint a Project Manager who is good at managing business projects AND who understands IT. While it might be tempting to save cost by giving the project management to someone internally, you must make sure their skillset and competencies are sufficient; or give them the support of an external professional who will transfer knowledge and coach as appropriate. IT project management fundamentals Like in any business practice there are a multitude of techniques, processes and methodologies available to ensure success. IT Project Management is no different. Unfortunately, different people may have very different opinions on which to select. Discussions often get surprisingly animated. If you’ve ever been in a meeting where Agile came up against Waterfall, you’ll know what we’re talking about! The fundamental practices of Project Management consist of: • Background processes and techniques • Project phases • Project methodologies The figure below lists the 7 main background processes in relation to the three main phases. Methodologies are discussed further in this article. IT project processes The background processes are often misunderstood for the project phases due to the lack of defined project processes within an organisation. Where they exist formally, these processes are often part of the Governance Frameworks and/or sometimes managed by the “Project Management Office (PMO)” i.e. those who set the rules for Project Delivery. Without a framework, or processes, to follow, the management of a project can quickly derail. It’s very common for organisations, large and small, to place less emphasis on (or completely ignore) this aspect of project management. This can be because the Project Manager doesn’t have time or because “it’s just a small project so we don’t need it”; as “we work in an agile way”. Either that, or because from a project management point of view, the organisation is not yet mature enough to have formalised those processes. If this sounds familiar, read on! Like most things in life, it’s about finding the right balance. In this case, the right balance for your organisation’s structure and culture. Whether the processes are outlined in a full blown framework or consist of a few bullet points, it’s a good idea to define project processes. They will help you keep control and ensure accountability down the line. Find out more on background project processes and how to implement them effectively What are the phases of an IT project? IT project is a catch-all phrase which covers different types of projects. They could be about equipment, such as servers (on-premise or cloud), networks, mobile devices, PCs and laptops or software; or anything else connecting or protecting them in between. Software projects could involve: • new applications bought in off the shelf and installed as is; • applications bought off the shelf but with an element of design tailoring and configuration (for example business workflow and process automation applications fall in this category); • in-house application development; • deployment of an existing application to a new department or division; • or even a mixture of all the above Regardless of the technology, devices or purpose, all IT projects have at a high level three broad phases. Before the solution is selected or purchased After the solution is selected/purchased but before it is rolled out During roll-out and beyond Depending on the type of solution involved as part of your project, each of the 3 main phases might be broken down into further sub-phases. The considerations, tasks, activities and techniques to manage those will also vary. At Digital Octopii, we use a checklist to assess where a project is at and to make sure we don’t forget any of the key success factors. See our project management services page to find out what’s on our checklist. Challenges of IT project management It is widely recognised that IT projects fail more often than they succeed. There are lots of software project failure statistics ranging from 60% to 90% failure (depending on where you’re getting your information from), but everyone’s agreed – once you’ve got a project started, it’s far from a done deal that it will finish well. There are many challenges to overcome in IT projects, and the cost of failure can be high. The truth is that projects are often easy to start but difficult to run well. This is usually due to not recognising the critical tasks that need to be done, or recognising them but not knowing how to do them well. Continue reading to find out the main things that tend to be missed out, what can be done to put things right, and the tell-tale signs that a project is heading south. IT project management methodologies There are many project management methodologies (some are more processes than methodologies) that have been used over the years. However, Agile and Waterfall are the two types of methodologies which are most recognised in the IT industry. These are most common, yet completely different in their systematic structure. Waterfall v Agile - a bit of history In terms of age, Waterfall is the older of the two and the more traditional method. It is straightforward and linear, with the phases flowing downwards; one starts when the previous one has been fully completed. This methodology was used throughout the 60s, 70s and 80s when highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades. By the time the 1990s came around, computing was thriving and it became clear that the Waterfall methodology just wasn’t enabling projects to go fast enough. This often resulted in projects being cancelled halfway through, sometimes even after a couple of years of activity. Often the project was completed but the business needs had changed by then. It was in 2001 that a group of world-leading software developers got together to devise a new methodology: the Agile Manifesto and the 12 principles of Agile software were born. Although the Agile approach uses the same project phases as Waterfall, it is the iterative nature of the method that makes the two distinct. The graphic below shows the comparison. The most significant difference is the repetitive phases – Agile is designed to enable change. Companies usually build better products if they can change specifications and designs based on the feedback they get from customers and continually test as the products are developed. Going through the phases more than once (many projects go through countless iterations) allows the Project Team to achieve smaller objectives more often, and re-evaluating if those outcomes are right. Questions to ask are: • Does this still meet the business needs? • Is anything missing? • Is it functionally correct? • Is there any positive/negative impact on other requirements further down in the plan? • Do any adjustments need to be made? Evaluating a bite-sized outcome is much easier to do, and so is changing it. If amendments do need to be made, going back over those phases is less time consuming, less confusing and less damaging to the project as a whole. This doesn’t mean to say that Waterfall is an approach you should steer clear of. Agile methodologies were developed for software development. Not all IT projects involve software development and even when they do, a Waterfall approach may be more appropriate for your IT project or for parts of it. Many organisations are more comfortable with a blend of both approaches. The strong governance provided by Waterfall approaches, particularly around budgets and change control, are simply indispensable in organisations where there are multiple programmes and projects. No project with an unknown budget and timeline would ever get past the approval stage. The Waterfall governance blended with the Agile, iterative approach to define, build and release functionality in blocks combines the best of both. It increases the chances of achieving the project objectives, i.e. of software being delivered; and changes to the ways of working being made and sustained over time. Managing risk with Waterfall and Agile Unforeseen issues are inevitable when running a project – you can’t possibly think of everything up front! To give a project the best chance, it’s essential to prepare for and manage risk by devising a risk management process before the project takes flight. A Risk Register can be used to capture, review and make decisions. Creating and maintaining this register is a start, but how it’s used is key. Highlighting the risks are usually a planned step in Waterfall. The team will aim to list all of the possible risks they could come across throughout the duration of the project once the analysis or discovery phase has been completed. The downside to this approach is that the risks may not be reviewed often enough and any additional risks found along the way may not be given the recognition required. Due to the rigidity of the method, it’s difficult to manage new risks that haven’t already been planned for or make sure changing risks get the attention they require. In comparison, risk management goes through a more cyclical and continuous risk planning exercise in an Agile environment. Technical projects typically have a higher degree of uncertainty, than for example, construction projects that very rarely deviate from the plan. The nature of Agile methodology helps to address this uncertainty without intentionally implementing a separate, formal risk management approach. The risk management is “built-into” the method because the constant analysis and adjustments to the teams’ tasks enable risks to be managed in a dynamic way. Methodologies, frameworks, processes & techniques are very useful management tools and no doubt are key contributors to the success of complex projects. However they will not lead to success on their own. “People” skills like leadership, communication, listening and emotional intelligence are also key success factors.

For more information on What is IT project management? talk to Digital Octopii