Project management is a serious subject that deserves serious attention. Here are a few statistics to focus the mind: 90 per cent of IT projects are late, 50 per cent run over budget and 80 per cent of organisations report a lack of project management capabilities as a key workforce issue. There are any number of reasons why projects might be late, but our panel of experts seem to agree it is all too easy to assign the blame to IT when the problem may reside elsewhere. ‘What worries me is that these projects are actually business projects, they’re not IT,’ says Ruth Buckley. ‘People are given licence to put the blame on IT if it goes wrong, but the reality is maybe 20 per cent of it is IT, the rest is all business.’ Stephen McCormack agrees there are issues with accountability. ‘Primary accountability within projects seems to reside within IT so IT is accountable whereas business tends not to be accountable for the success or failure of the project.’
Tony Carroll argues IT ‘can’t be accountable for the business benefits that arise out of the project. You’re handed a project the business people aren’t clear about or are uncomfortable about owning. Suddenly it becomes an IT project when it’s implemented. People wonder why the business benefits haven’t been delivered, but you can’t expect IT people to deliver business benefit because they don’t know anything about the business.’
The difficulty is ‘getting buy-in from the outset. It’s critical before the project starts to understand who is going to own the project, who is going to deliver on the benefits realisation and who is accountable’. Unfortunately, too often this doesn’t happen. ‘If the project is let go off the rails and there’s nobody accountable for it other than IT people, you’re put into an unenviable position. Like the UN, you can’t win.’
Collaboration helps
Eimear O’Broin believes things are changing. ‘It’s a much more collaborative exercise,’ she says. ‘One of the things we’ve done internally is train up the business in project management as well so that it’s a true collaboration. Everybody’s working to the same method. It’s changed the way business looks at projects as well – they’re more structured in the way they approach them. They know if there is scope creep, it’s going to affect the timeframe or resource allocation and they can live with that.’
And she makes the telling point: ‘IT needs to look at it from a business perspective as well. We use a lot of jargon that separates us and builds barriers. We really need to speak in business terms. We all work for the same organisation, we all have common goals at heart. The most successful projects are where the business and IT work well together and communicate together.’
With collaboration comes a greater need for understanding. Pat Millar says: ‘There needs to be training on the business side. When we talk about scope definition, are we agreed what it is? Are we just assuming you know what it is.’
And there’s a change on the IT side as well as it becomes more and more business-driven. ‘When you look at the CIOs and IT directors of the future – more and more of them will be appointed from the business. When that happens, there’ll be a different attitude within IT as to what IT does.’
O’Broin agrees. ‘It’s absolutely essential that IT people understand the business. We can’t have it both ways. We can’t, as a body, criticise the business for not understanding IT if we don’t do the same.’
But Carroll says it’s still ‘very hard’ for IT people to understand the business community. ‘One of the things we’ve done is to send some of our project managers on Medicine for Management courses to let techie people understand what the business is about. Sometimes we take people from the business community and train them up as project managers then send them back out into the community. But that’s a very expensive exercise.’
Kicking up a fuss
Millar argues IT organisations sometimes ‘don’t do themselves any favours because they’re not strong enough. Okay, the business has to have sponsorship, do the peer document, define everything upfront, the scope is defined, it says what the role of project management is, the role of the steering committee and the role of sponsor is such and such. As the scope starts to creep, the IT people kick up a bit, but they don’t kick up enough and they don’t make the sponsor go and accept the scope creep in writing.’
Too often, they’re too busy in the mechanics of doing the project. ‘They’re brought in because of the skill set they have around the operational piece of doing a project but they forget very much about communicating back to the steering committee, making sure they really understand about the scope creep. They’ve told the steering committee but does the committee really get it, does it really understand what it means?’
This leads to a situation where project managers are blamed when a lot of the problems may be down to organisational type issues. ‘Did they get the right resources, did they get proper sponsorship, when they escalated to the steering committee, did it do anything? It’s not good enough anymore to just do the project well. The communication, the people skills, the soft skills, that bit is much more important,’ says Millar.
Carroll agrees communication can be an issue. ‘You sometimes let projects drift on when you know in your own heart the project isn’t going to deliver at the end of the day or the scope has changed. The business community might want to continue [but] I suppose we should be bold and brave enough to say ‘well no, we’re not continuing with that and we’re not committing resources to it’. That’s very, very hard to do. But if you’ve limited resources you have to look at the projects that are going to be successful and not assign resources to projects that are going to be 70 or 80 per cent successful. We should be more forceful and honest.’
O’Broin concurs. ‘I think business does appreciate honesty if something is not going to work.’ Not that such directness will always result in the project being terminated. ‘Sometimes when you are honest, they would still want to continue on,’ says Carroll. ‘We should have a business decision from an ICT perspective because they’re our resources and it’s costing us money.’ A point echoed by O’Broin. ‘It comes down to IT being a stakeholder as well and there has to be a deliverable to IT.’
Assumptions can be dangerous
There are other problems. Millar warns there can be ‘a whole host of assumptions not listed in the scope document. For instance the quality of resources. If I want someone from finance or supply chain, I don’t just want anybody, I want the best person, the person the business can least afford to give up. If you’re in a large project and you don’t have to fight for the resources, or the business is just giving you that resource, I’d say 90 per cent of the time, it’s the wrong resource.’
Consultants would be putting in assumptions very clearly. ‘There’s no reason why internal organisations shouldn’t do the same. A lot of the time people don’t do it to enough detail internally because they’re using an internal resource and the attitude is ‘so what?’. An external organisation will say when you start to deviate from assumptions, ‘hold on, stop now’. The business is putting that person forward, if that person isn’t working out, it’s a business problem.’ McCormack agrees the project manager ‘needs to be strong in standing up to the business’.
But you have to accept, Carroll says, ‘people who are really good on the business side are difficult to attract and retain. They’re in such demand, there’s such a high premium on them’. Miller agrees. ‘You want the best people in the business but you have to be realistic – you’re not going to get the best people in all areas. Instead of the best guy, maybe you’ll get someone good in finance and the best guy one day a week. A good project manager will do that. Very often, the mistake we make is we define the roles and responsibilities, we go and look for people, we don’t get what we want but we don’t go back and revisit the timeline and look at the resource. We just complain about it. We don’t go back and say to the business ‘you’re changing the goalposts and so are we.’
Buckley says that’s why methodology is important. ‘Methodology gives you the argument. If you have a sponsor who refuses to accept the fact you need A, B and C, you can very easily go to him with two or three options and say ‘if I get that resource it’ll take this much time and if I get this resource it’ll take that much time’ and you’re taking your personality out of the equation. You’re presenting a very cogent, logical argument that even the most bullish person is going to have to accept.’
What is a successful project?
Given the obstacles, how do you achieve a successful project? Buckley says ‘rather than going with scope, I go in and ask ‘how will you measure success’? That brings out a lot of information, valuable information. You can have a very successful project that delivers exactly the scope that everybody signed up to, but the user perceives it as a failure.’
According to Millar, ‘a successful project is one which achieves the objectives laid out at the start to the full degree laid out at the start, on time and within budget. If it’s not on time, it can still be a successful project, just not as successful.’
O’Broin says that ‘even if it’s not on budget, it can still be a successful project. IT is a stakeholder in the project as well. A really successful project is one deemed a success to the business but also to IT.’
Carroll points out ‘very often there are a considerable number of intangible benefits that aren’t documented or are not seen as part of the project that go unnoticed. I think you have to have a flexible approach to the area of benefits realisation because from the business perspective they don’t always understand what benefits they’re hoping to achieve at the end of the day.’
Sometimes the big benefits are the simple things the project delivers that you don’t even think about. ‘The fact information would be available on a 24/7 basis and available in an integrated fashion, how you quantify that for some of the business units we would be dealing with would be very difficult, but for a doctor or nurse to get access to even basic demographic information is a huge bonus. They might not identify that.’
His department runs benefits realisation workshops during and after the project. ‘We get in the professionals that deal with the system on a day to day basis and ask them to tell us the top five things useful to them and the five things that really irritate them. If you don’t talk to the punter on the street using the system, you’re not going to get a view of what it means to somebody on the ground.’
Who is happy?
Success can be relative, according to Buckley. ‘You might have a situation where the sponsor might be very happy but the user might not.’ McCormack agrees. ‘We deem a project successful that meets or exceeds customer expectations. That’s a very broad statement. If it meets sponsor expectations but may not meet everybody on the ground’s expectation, it’s a very difficult thing to manage.’
Millar says it’s important to try and look at what the benefits will be for a range of people. He gives the example of an ERP project. ‘Very often senior directors in a company decide they want or need an ERP system. They engage somebody to come in and help them implement it. They have a team of their own people and consultants all working together happily. You start working with middle managers. They have goals. Their goals would not have been put into the initial cost/benefit analysis that resulted in this decision. They’ve got other objectives. They need to be worked into the scope and you need to look at all the levels of the organisation and try and identify the benefits, tangible and intangible, that could come out of it. You’re better off doing that early on, even if it takes longer or slows things down a bit. If people are saying on the ground ‘this is what I want to get out of it” and you know they’re not going to get it, you’re better off dealing with it there and then and trying to change that expectation.’
A good project manager
O’Broin says presentation, communication, ‘interpersonal relationships management’ are very important. ‘That’s the piece that’s really changed for project managers. The ones that do well are the ones that get that bit right. Because you’re dealing across the organisation, the people out there getting to know the business, understanding the people in the business, understanding the inter-relationships between the different functions, they’re the ones who are going to be the successful project managers of the future.’ Millar agrees it’s ‘a completely different skill set. It’s about pushing, pulling, coaxing, bullying’.
O’Broin says anybody can be trained on the methodology of project management. Business managers are running projects all the time, she suggests. ‘Everybody can benefit from project management training. We all project manage all the time. It’s a frame of mind. You can improve everyone’s approach to project management – you can help everybody, everybody can improve with some training.’ But really successful project managers are the ones with the expertise in bringing people together. They need to have ‘emotional intelligence’ and ‘to know how to move and shake within the organisation’.
Caroll says this is important when it comes to team dynamics ‘because you’re going to have people with different skills coming together with different drivers. You can’t apply the same measure from a management perspective to them. It’s not one size fits all. You can have horrendous difficulties if you don’t recognise everyone has a different skill set, you can’t treat them all the same. That’s a skill all of its own. The fatal mistake people coming from a technical project management background make is if they automatically assume all these people working for them should be treated in the same way. It’s about knowing which buttons to press because everyone has different buttons.’ He describes project managers as ‘change agents. Project managers have to be passionate about the project. You have to have a fire there to make it happen. It’s not just a job – good project managers are few and far between. It’s a gift at the end of the day. You have to believe in the project.’
McCormack believes project managers ‘learn by doing. Coaching people into project management roles is very important, giving them small projects where they can be successful. I’m a great believer in coaching people into project management roles’.
It’s a tough job, says Buckley. ‘I don’t think anybody can be parachuted in as a project leader without having participated for a lot of time in project teams of different sizes and natures. I think it is one of the toughest jobs. You’re in the sandwich between the sponsor, your boss and the project team.’
Millar describes it as ‘a thankless job. There’s a huge amount of change, trauma, grief, pain, especially at the end. As soon as it’s over, the last thing people want to do is to look at it in any way. But because you don’t look back you miss a learning opportunity, you miss being able to look at the benefits realisation. It’s no sooner finished then someone’s talking to you about your next project. In fact, it’s probably not even finished and they’re talking to you about your next project.’
Buckley says it’s important to look back. “I think it’s like climbing Mount Everest and stopping to have a look at the view. Sometimes in a project the benefit is only realised a year following the implementation. That’s why it’s hard sometimes to keep the morale. Actually, it can be exhausting. After three or four years of constant and high pressure projects, it’s no wonder people want to get out. Good ones are hard to keep.’
Ltd
