2. Why is IT project management different?

Project management has been around for ages and it is used in all sorts of industries, such as construction, engineering and manufacturing. Even though there are some common areas between IT project management and other industries such as they all cover initiating, planning, executing, controlling, reporting, and closing out a project, there are some differences within IT that makes being an IT project manager more challenging.

Some reasons why IT project management is set aside from the more traditional project management are:

• In IT the major focus is the development and implementation of systems or products, therefore an IT project manager is also responsible for the development, configuration management, and quality assurance activities.
• There are rarely two IT projects that are exactly the same, even a hardware upgrade project will have new and unknown elements to it which makes it different. This could be due to environment, infrastructure, hardware or people skills.
• Most IT projects will need to integrate with existing systems that are currently being used in the business.
• People find it hard to visualise the end product on IT projects, so gathering requirements is key.
• Software systems are not just about the functionality, they need to also address areas such as security, performance and scalability.
• IT Projects are usually higher risk projects, due to new technology being used.

I have heard many project managers who have taken on an IT project say “I didn’t realise we needed to do that” or “How do we release the system into production?” the week before the go-live date. I have even seen issues and faults logged on a system released for user testing being managed within emails! A big part of managing an IT project is knowing what technical decisions and environments need to be in place and at which stage of the projects life cycle.

Regardless whether the company that you work for produces software, buys software or uses a consultancy company to build software, the delivery of the project will have the same distinct stages:

1. Understand the business problem and why we are doing it.
2. Define what is needed.
3. Work out how we can deliver it.
4. Build or implement what needs doing.
5. Test that it actually does work and meets the business need.
6. Release the software to the business so they can start using it as part of their daily business.
7. Support the system in the business environment.

An IT project will go through these stages regardless whether you are running a traditional waterfall, hybrid (a combination of agile and waterfall) or an agile project, the difference is you may have multiple iterations of stages 2 - 6 with agile approaches.

Over the years I have seen so many agile projects lose track on what the project purpose due to the project proceeding with little management. There are active discussions on whether a project manager is needed on agile projects and can be seen, by some, as an unnecessary expense as the development team has it all in hand. The project manager role on an agile project is even more important than in a more controlled approach (such as Waterfall) however, the questions you ask your team and how you manage the project are different but the role of a project manager is essential.

IT project management is no more or less important than project management in any other industry, but in order to manage an IT project successfully you need to be aware of how the development, configuration and software quality processes work.

Is it a project?

Many times I have heard the phrase “it’s not a project, it’s business as usual” when really the activity is a project. Another example of not understanding projects is where large projects are defined as a “programme”, just because it is complex, has many elements or because it sounds more important.

There are many definitions of what characterises a piece of work as a project and you may find that your organisation has a standard already set. If this is the case then you should adopt that approach. If not, then the following is a good starting point.

A project is a set of activities that are not repeatable and you are likely to only perform them once. An example of a project would be upgrading a specific server versus a “business as usual” activity such as adding a new user account to the network.

A project will:

• satisfy a business need, solve a problem or increase efficiency.
• have a defined scope.
• have funding approved.
• have risks.
• have a defined set of stakeholders.
• have a defined set of people responsible for delivery.
• have a defined start date.
• have a defined end date.
• have a temporary team.
• it will have an IT element.
• it’s unique.

What’s a programme?

A programme differs from a project, as it is normally made up of a number of different streams of work that have been grouped together to deliver a specific set of business objectives or goals. The streams of work that can be included in a programme are:

• projects in their own right.
• changes to business processes.
• business as usual activities.

Objectives or goals are normally grouped together due to a strategic decision, where the organisation wishes to improve their business benefits, processes or efficiencies. Programmes are normally part of an organisation’s vision for the future.

What’s a portfolio of projects?

A portfolio of projects differs from a programme because it is purely a collection of projects that a project manager is responsible for delivering. The projects are grouped together for one or more of the following reasons:

• the projects relate to a common business objective or goal.
• the projects are dependent on each other.
• the projects complement each other.
• to improve overall efficiency.

What’s portfolio management?

In Information Technology it is fair to say, that there are more projects ideas created than there is time or money, to physically to complete them all at once.

This means your organisation needs to have a way of prioritising and selecting a subset of projects that will increase their profit, make efficiency savings and get the best return on investment for the business. This is what portfolio management is about. Projects are prioritised against a set of criteria that allows your organisation to get the best value for money, at the right time and meet the business demands.

Portfolio management is different to project management, but a project manager can be responsible for ensuring a portfolio of projects are delivered successfully.

What’s “business as usual” (BAU)?

“Business as usual” is any task or activity that is carried out as part of a person’s normal work duties. It will normally have the following attributes:

• it can be repeated multiple times.
• it follows a pre-defined process or set of steps.
• has very low risk associated to it.
• does not require additional funding, it is budgeted for as part of the organisations operating costs.

Why start a project?

Some people may think IT projects just appear on their list of work to manage, and they don’t need to consider why they have arisen, but there is always a reason why a project has been formed. Most projects are commenced due to a business idea that has been factored into an organisation’s business plan. If a project isn’t driven from a business need, then you should be questioning why you are doing it.

Regardless of whether your organisation undertakes their projects in-house or through an external IT supplier, the reason why a project has come about is the same. Most projects are started because:

• there is a common need to do something.
• a strategic decision has been made to invest in a change to the business.
• there are efficiency savings that can be capitalised on.
• there is a need to keep up with changes to technology.
• existing systems or infrastructure have come to the end of their life.

IT projects can fail, but why?

In my experience I have yet to find someone who can hand on heart say that one of their projects went exactly according to plan with no surprises on the way (if you are the first then please let me know). Now, a completely failed project is easy to identify as the project has been canned and the team have been sacked, but that is quite dramatic. There are more subtle indicators that you are managing or are involved in a failing project.

• Your project is costing a lot more that it should have. At the end of the day cost is one area that the management team will be looking at and it needs justifying why it cost more. This could be for a number of reasons such as, an unknown cost was identified, more people were needed in order to bring the project in on time or because not enough was known up front before the team started working on the solution.
• It is taking a lot longer than expected. If things take too long to see results then people loose interest, also the longer it takes the higher the cost. The reason why some projects do take longer can be due to an inappropriate deadline imposed at the start of the project that was impossible to meet in the first place. If this is the case, then it is questionable whether the project should have actually started. Estimates can also be at fault for things taking longer due to your team guessing how long tasks could take and believing giving a figure is better than saying they don’t know or if an accurate estimate was given by your team, but it has been “tweaked” along the way as “surely it can’t take that long to do?”
• The deliverables do not do what they are supposed to do. If a system doesn’t do what the business needs then it has no value and will not be used, therefore it is an unrecoverable cost. Rushing through the business requirements and not having a clear understanding of the business problem will be contributors to this failure.
• No one is happy about working on the project. If your team is unhappy then there is normally a reason for this that relates to, excessive workload, clarity on progress is needed or a dysfunctional team.
• Functionality and tasks are being cut out in order to make a deadline. Although IT projects have a change control process, from experience this is normally used when more is requested rather than less. If features and quality tasks such as testing is being reduced to make a deadline the alarm bells should be ringing loudly. Cutting out planned tasks to meet a deadline normally means a substandard product will be released to the users.
• Lack of process used. We all use processes in our life, such as driving to work each day. IT Projects are no different and if your project is not following a methodology or process then it is likely to go off the rails. People understand clearly defined processes and most adhere to these. Having defined processes in an IT project is key to them running smoothly, there should be processes for how the project is to be managed, how the development team are to work on one code base and testing processes to name a few.
• Too much change. Don’t get me wrong change is a good thing, but sometimes we can either change too much at once or be constantly changing things that we have just implemented. Change is good, but only when is managed and controlled appropriately.

How to succeed!

IT projects can succeed and be very successful, so whats the key?

• Ensure change is managed - Change happens in most projects, if not all, but it’s how you deal with the changes that can either make or break a project. Change management is needed regardless of what project management methodology you are using and needs to be controlled. Having change control processes, accountability, authorisation processes and principles, outlining when changes can be reviewed and introduced into the project, will help your team know what to do when a change is suggested. If you have no processes or rules then change on your project could turn into a bun fight and deliver nothing or a solution that doesn’t do what the business wanted because the vision was lost. You also need to remember that changes will have an impact on cost, people and the delivery schedule.
• Do not let the project be micro managed by the boss! - This is sometimes easier said than done and who is the boss on the project? Well, the answer kind of depends on what your role is. If you are the project manager then the boss is likely to be the project sponsor or customer(the person funding and driving the vision), but if you’re a developer then this could be your lead developer, software architect or the project manager. So, this point actually applies to a number of people. If you are responsible for a team, then you need to remember that each person on the team has a purpose and role, otherwise why are they there? You need to have an overall understanding of how they are managing their time and tasks, but you need to also allow them to have some flexibility and creativity on how they achieve this. This also applies to the project manager, they will need information from the whole team on the progress, direction and problems that are currently happening, but I wouldn’t expect a project manager to start rolling up their sleeves to carry out a code review. Micro management normally creeps in when someone is concerned or not getting the correct information about the teams or projects progress and therefore feel that to get an understanding must get more involved. If this is the case then, it is worth while sitting down with the person concerned and understand what the problem is and how you and your team can provide this information without them getting more hands on.
• Don’t rely solely on gut instinct - I am sure most people have in their time on a project thought “hmmm, I am not sure about this”, but can’t figure out why? This is your gut instinct talking and although some of the time it is proved right, you shouldn’t rely on it solely. If you are worried about some aspect of the project then this should be flagged as a concern and then proven or worked through with the team. This way the gut instinct has been formally logged and addressed. Thus, if someone asks about it later you or the project manager can show how the team came to your outcome.
• Ensure the business is working with you- Whether you are working on a traditional waterfall project or an agile one, it is key that the business is represented on the project team. For projects to be successful they need to meet a business need, so if the business is not working as part of the project team, how are you going to know what they want or whether is works as they expect? Remember your expertise is in IT not the business, so this needs to be represented.
• Eradicate tunnel vision, see the BIG picture - I think anyone can suffer from tunnel vision on a project, it is easy to get wrapped up in what you are working on and forget how it all fits together. However, for a project to succeed everyone must understand what the project is trying to achieve, how it interacts with the current business and how the project is going to deliver. Understanding the bigger picture doesn’t mean you need to know all the details of what each team member is working on, but you do need to understand how it fits together. One way that tunnel vision can be prevented is by the introduction of daily stand up meetings or 10 at 10’s where the whole team meet for around 10 minutes to discuss what is happening for that day and any issues or help needed raised. Visual prompts around the room also help, such as a vision sketch showing the business requirements that need to be delivered or the architecture diagrams on how the system fits together. You’ll be surprised by how many times your team will refer to these posters on the wall when talking to each other. Having the key information on the walls (flip charts or whiteboards will also do) makes it much quicker to refer to than finding the correct document and diagrams, plus they seem to get updated when things change.
• Have transparency - Nothing should be hidden from anyone in the team. Good communication is key to success. This actually goes further than the team that is implementing the change, it needs to cover the business and anyone who is affected by the change. By having transparency within the project usually means that problems are captured and dealt with earlier and it is a known fact that the earlier in an IT development a problem is found the less it will cost.
• Outline how the project is to run and ensure everyone understands this- This is something that the project manager will undertake, however it should be done in conjunction with the team. In the past, I have had some project managers say, “well we use Prince2 and thats how we are going to run the project” To me, this makes a huge assumption that everyone on the team understands the methodology and also the key elements to running an IT project is how the software development, configuration management and quality assurance of the solution is to be carried out and Prince2 does not cover these. The approach of how your team are to deliver the project needs to be understood and agreed by all. If you do not have your teams buy-in to how the project is to run then implementing the plan will be tricky.
• Tell the TRUTH - This goes in hand with having transparency. Telling someone bad news or something you know that they are not going to like is hard, however, not telling them early enough in order to do something about it is much worse. So many times on IT projects I have heard the words “We are CODE COMPLETE” but when you ask has it been unit tested and did it pass, I hear “Umm not yet”, to me that is not code complete. Code complete is that is has passed the tests and it does what is meant to do and is ready for release for system testing.
• Don’t guess how long something is going to take - Its pretty obvious really, but it is a situation that a lot of developers are put into. The problem with this is once a date is given you are committed to it. It is better to say we don’t know because xyz…, rather than put your finger in the air and guess.
• Make sure estimates have contingency if there are unknowns - If you have to give an estimate and you are not comfortable that you have enough information or certainty from your team then add contingency to the task to cater for unknown issues.
• Question deadlines if they seem unrealistic - I’m sure most people who have worked on an IT project have heard the comment “Surely that can’t take that long?” or it has to be done by a certain date. First question is, where has the date come from? Most of the time you will find that someone has just decided that that’s when they want it by, but there is no real business demand for a particular date. Sometimes, however a project can be date driven and if this seems unrealistic then, rather than try to squeeze as much in a possible, you should be addressing the unrealistic deadline and either reduce what is delivered or harder still, determine whether the project is actually viable.
• Make sure non-coding tasks don’t get missed off or cut - When deadlines get closer in IT projects and development is still underway the non-coding tasks start to disappear or reduce in time. Coding and development is only part of an IT project and the quality assurance part (testing and making sure it does what it should) is key to the project being a success. Remember you only get one chance to introduce the new functionality to the user, make sure you and your team are proud and confident in what they release. If they are not, then you know it’s not ready and you or your project manager is going to need to manage expectations.
• Don’t rush into coding, understand what the actual problem is first and what the customer wants - You may think that by showing the customer what you can do through a prototype is great (and sometimes it is), but coding without understanding what the business problem is and what they need, could lead to delivering the wrong thing or creating unmanageable non-supportable code. Even agile projects need to have high level requirements before any sprints can be planned and coded.
• Understand what you are coding by having the architecture defined- Any developer will need to start building their code on a firm architecture, if this has not been defined and understood then you can end up with workarounds, spaghetti code or worse, the need to start again at a cost. The system architecture is driven from the requirements and needs to be in place and understood by the development team before coding and should be kept up to date throughout the development phase.

IT project management is about control and vision and the job of the project manager is to ensure that the project is controlled and all the team have a clear understanding of what the project is trying to achieve and how they are to get there i.e. the vision.