Directors' notes

Feature

Directors' notes

Julie Senior, special report editor
Forget the project management manuals, here is some advice from five people who have been on the front line. We asked them, "What makes you think, I wish someone had told me"?

Advice: Throw out the IT department
Colin Saunders, IT director, Warburtons
Scrap the IT department. There is no such thing as an IT project, and therefore no need for an IT department. Successful projects are about benefits-realisation, and that requires business ownership. Too many senior end-user managers abdicate ownership and expect the IT department to deliver business process change, financial benefits and service improvements.

Don't get me wrong. I am not advocating the abolition of the tasks and jobs that are performed by the personnel in IT. However, there must be a better organisational model, one that truly reflects the nature of what IT delivers for business.

Practically all business improvement is enabled by technology. We help make businesses better. But we are neither the creators nor the consumers of information, and we do not perform business processes. Hence there is no such thing as an IT system.

When we deliver an IT system, what we are saying is that the business is improving itself and technology has enabled that improvement. Responsibility for the improvement and realising the benefits of the investment lie with the business.

If there were no IT department, there would be no scapegoat and nowhere to look but in the mirror. Don't blame us if it all goes 'Pete Tong'.


Advice: Seek ways to simplify the solution
David Rippon, director of pragmatic management services and chairman of the IT Directors' Forum, Elite
The most important advice that anyone can be given in relation to project management can be expressed succinctly as, keep it simple. "No matter how complicated the solution may seem to be, always look for ways to simplify it and focus on that simple solution. If the project seems too large and complex, then find ways to break it down into phases, each of which can be managed separately. There will always be three strong influences seeking to increase complexity in your project:

  • Your users will have expectations of what can be delivered which will not be possible within the project budget
  • Your technical staff will want to increase technical innovation without adequate consideration of the overall benefit to the project
  • Everyone associated with the project will become fully paid-up members of the "not invented here" party.


These influences will result in the following early warning signs of project disaster:
  • Scope creep as the users fight to get incremental functionality into the project
  • Technology issues starting to consume more management time than business issues
  • An outbreak of jargon resulting in the project team speaking a different language from end-users.



Advice: Never assume anything
Peter Evans, chief technology officer, Callserve
A piece of advice I wish I had been given earlier in my career is that assumption is the mother of all muck-ups. At the planning stage of a project, most timings on activities are calculated by assigning set times for set tasks - assuming that a man-day on a project is indeed a day spent on development work.

It is important to remember that developers often have a dual role. They are involved in developing the code or product, and at the same time providing last-level support if things go pear-shaped.

In my experience, this high-level support can range from 30% to 70% in terms of time and effort - something that cannot be planned - leading to compressed timescales for the core development work, which often slips into the essential, and sometimes overlooked, area of testing.

Another assumption on the testing phase is that all will go better than it ever does.

I have learned that the best way to get around this is to plan with resources that have had the extra support/testing times added at the start.

It is not a total solution, but it gives a truer expectation to the business and enables a more realistic timeframe to be managed - assuming that the scope of the project has not changed during its life.

That, of course, would be an altogether different story


Advice: There are no 'magic bullet' solutions
Roger Elvin, research fellow in information systems, Cranfield School of Management
Asking for a single piece of advice is like asking David Blunkett to identify the one action that will remove crime from our streets. The management of IS/IT projects is a difficult and complex task and there are no magic bullet solutions. IS projects are intrinsically uncertain.The management complexity arises from the necessity to deal simultaneously with several tensions:

  • Innovation versus risk
  • Learning versus control
  • The need for organisational change to deliver business benefit versus stakeholder resistance to change
  • Multiple stakeholder perceptions of the purpose of the project
  • The need to deliver value to the organisation versus managing efficiently to satisfy time, quality and cost objectives
  • Managing detail and the big picture.


To cope with this complexity requires IS project managers to challenge some of the received wisdom promoted by the supply-side of the IT industry.
My key messages are:
  • IT may be a necessary enabler of change but it is the change itself that delivers business benefits, not the IT
  • IS projects come in many shapes and sizes - a one-size-fits-all approach to managing them is unnecessarily restrictive
  • IS project management is a multidisciplinary, multiroled and multiskilled activity that is best conducted by a team rather than a "superhero" project manager.
  • Delivering benefit and satisfying time and cost budgets are complementary but independent project goals
  • Delivering benefit is not simply achieved by avoiding time, cost and quality over-runs
  • IT project management best practice is necessary but not sufficient to deliver business benefit from IS projects."



Advice: Retain your honesty and integrity
Colin Beveridge, IT management expert and commentator
John Lennon once sang, "Life is what happens while we're busy making other plans", and even the best project manager will discover there are many, many factors beyond their control, despite rock-solid planning and risk anticipation.

That is what makes project management so interesting: the challenge of delivering the goods, sometimes against the odds - and even the gods.

But no matter what pitfalls and opportunities clutter the critical path of a project, project managers should always have two success factors completely under control - their own honesty and integrity. If you remain honest to yourself, your customers, suppliers, colleagues and staff, then you will be halfway to being a good project manager.

You will not compromise the truth for the sake of fear, popularity or convenience. Your reports will not gloss over, nor disguise, the actual progress achieved, nor paint too rosy a picture of the way ahead, unless it can be justified.

Your personal integrity will be a vital ingredient in making sure that everyone trusts you to manage your project effectively and it will help you to get the best out of people - especially when you need flexibility and commitment from others to get the job done.

I believe your success will depend more on character than technical background. But that does not mean you should neglect the opportunity to improve any aspect of yourself - even failures can help you to grow by learning how to avoid future mistakes.

So remember: honesty and integrity will help you to achieve and sustain a well-earned reputation as a good project manager. They will also help you to get a good night's sleep, even when your project is heading south.

Start with a good briefing >>
Why projects fail >>

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in February 2003

 

COMMENTS powered by Disqus  //  Commenting policy