The Do's and Dont's of IT projects

Nowadays, even non-IT staff get involved in IT projects sooner or later. Unfortunately, these projects are often a source of stress and frustration. So, how can we avoid unnecessary hassle, conflicts, and anxiety? What should we do to (and not do) to ensure the project runs smoothly, and delivers the best results?

I asked a few experienced IT project managers what they've learned.


Clear and Guarded Project Scope

Guard the scope of the project like a dog guards its territory. Take enough time to start the project well. This can be done by means of a kick-off meeting, supplemented by a plan of requirements that is as complete as possible. Identify all necessary resources and people that are needed during and after the IT project. Do not forget to consider how the product will be managed after the project has ended.” - Olivier Van Eesbeecq

“Many large projects fail because business circumstances have changed - creating a considerable gap between the agreed-upon scope and budget, and what the company needs and pays by the time the project is delivered. (...) It’s regularly forgotten to verify if the requirements or final product - the intended outcome  - are even possible to achieve. It’s painful to see promises being made that later cannot be fulfilled. Clearly define project goals, business case, scope, requirements, intended outcomes, risks, team, and planning. Make a clear schedule, and Keep It Simple Stupid. Use Gantt charts and/or project management software, and define a change control process. This makes progress clear and establishes necessary sponsor approvals. Communicate clearly and enough, especially when starting the project. Never do more than what is asked.”  - Val Coucke

 “The scope of a project is prone to change when the intended outcome is unclear - because businesses can’t always express their idea or intended result very well. For this reason, the requirements should be properly analyzed - to have a non-technology investigation: “what do you mean with this?”, “what do you want to accomplish with this?”. Having a good facilitator to bridge the gap between business and IT during this investigation is crucial. It’s also important to set clear and truthful priorities - distinguishing between what is really crucial to achieve the intended result, and what are things to improve efficiency - or simply based on assumptions and current way-of-working. The more critical and thorough this analysis, the less costly rework and frustration you have later on.” - Patrick Luyts

It's a common challenge to keep a project focused. Often, this is due to unclear assumptions: what are the reasons for doing the project? And what are the conditions for these reasons to be valid? If these aren’t explicitly described before the project is undertaken, things will start to drift more and more as things go on. Make sure the reasons (and underlying conditions and assumptions!) are clear and known, and regularly validated. If one or more are no longer true, the project may not be valid anymore either. At that point, it might be better to rethink or cancel the project than to keep burning time and money on it.


Clear and Dedicated Roles (and The Right Person For Them)

"Project management is a profession! Don't expect every IT person to be a good project manager. Look for the right person with relevant experience to supervise the IT project. Do not only look at availability within your own team or company, but also dare to call on people who have the right knowledge and skills. Experience shows that external project managers achieve better results than your own people. They look at things fresh and without preconceived views, and dare to question past practices or procedures. Be critical when deciding who will work on the project. Repairing mistakes is more costly: it causes double work and puts pressure on the project." - Olivier Van Eesbeecq

"Testing in phases and sign-off of milestones requires a lot of business involvement and backfill from key users. The operational readiness to support the application has to be checked very meticulously. (...) Don’t assign a 100% technical person as project manager. - Patrick Poncelet

“One of the biggest problems is insufficient ownership; too many cooks in the kitchen without clear responsibility for the end result. On the other hand, there are often many people simply focusing on their own little piece. Responsibilities need to be balanced with resources and mandate. (...) Don’t let the accountants run IT. - Patrick Luyts

When roles are unclear, people get in each other's way, get confused, and don't get what they expect. To avoid this frustration, ensure:

  • the intended end result (both product and business outcomes) is clear
  • responsibilities and expectations are unambiguous
  • people have sufficient resources and clear mandate (who has the final word on what)


Clear and Effective Communication

“Preparing important project moments in advance can prevent delays or frustration. Therefore, teach the 'business' the usefulness of 'clustering tasks'. Example: plan a time of 30 minutes before and 30 minutes after a project meeting in your agenda, so that you can prepare the meeting well and finish your notes after the meeting. You want to avoid taking part in meetings unprepared or not documenting afterwards. - Olivier Van Eesbeecq

“IT projects are 33% technology, 33% change management/training, and 33% resource/capacity planning.  - Patrick Poncelet

"Keep the projects manageable and ensure clear communication. I have seen some projects grow so large that they are no longer comprehensible, and by the end nobody understood them anymore. (...) Keep communicating and involving people (business) in the story. Why are we doing it, and what is our purpose?"  - Val Coucke


Conclusion

The root cause of many (most?) project issues is a lack of clarity on the what, how, and why of the project. When the project is first started, everything seems simple enough. Spending time on these "details" might feel like a waste of momentum (or not Agile). But what is left implicit and assumed soon becomes a source of confusion and frustration. It's said that an hour of preparation saves four hours of frustration. Many teams, eager to please and start building, have yet to take this to heart. 

To close this article, a word on the necessity of properly closing the project: 

"There is nothing so annoying as not putting an end date, and not gathering lessons learned. Look back and see what went right and wrong. This is how you learn, especially working in the same company with the same resources and dynamics. And finally, declare a successful project, and celebrate it. A pat on the back always helps." - Val Coucke 

Thanks to Olivier Van Eesbeecq (Head of ICT & Facilities), Val Coucke (Information Technology Operations Manager), Patrick Poncelet (EMEA IT Service Delivery Manager) and Patrick Luyts (IT PM - retired) for their contributions.

More items

Would you like to receive relevant case studies, articles, and other information?

{{ newsletter_message }}

x

{{ popup_title }}

{{ popup_close_text }}

x