Making IT Projects a Success - 2

Continuing on Part – 1 of my article “Making IT Projects a Success”, we now take a look at the key role that the Project Manager and the Project Team plays in the Success of a Project.


6) The Project Manager (PM) – Central to the success of projects is the personality traits and skills of a PM. He juggles the act of balancing scope, cost and time (often time to market) with an eye on meeting the defined success criteria.
Ten ways in which a PM attributes to the failure of a Project include:
1.makes a project plan and schedule that is unrealistic with inaccurate cost estimates.
2.fails to recognize early signs of trouble in a project.
3.does not have in place a checklist on everything that can go wrong, analyze its consequences and put in place corrective measure.
4.does not ensure that the project demands & team members’ capabilities is a perfect match. is often unable to manage dysfunctions in a team.
5.ineffectively handles performance issues.
6.does not motivate the team when the enthusiasm begins to wane due to fatigue and project issues resulting in delays and hence the start of what we call the Domino effect.
7.fails to ensure day to day operational issues and pressures from other projects do not impact his project and staff in anyway.
8.Does not possess problem solving ability, especially performing one with consensus.
9.Poorly handles RAID – Risks, Assumptions, Issues and Dependencies.
10.RAID is an important consideration on which I would like to elaborate a little more:
Risks – Analyzing risks during the start of the project (ex: in the present state) is a given but the ability of a PM to place oneself in a future state (ex: during the actual cut-over to production) and analyzing the same is where the real challenge lies.
Assumptions - Making assumptions are a habit and each individual does it to varying degrees. It is amazing to reflect upon the number of assumptions that we make on a daily basis. To be on time for that morning meeting, we assume that the alarm will ring, there will be hot water in the shower and so on. Carry this situation to a large Project Plan and the PM needs to let go of this habit.
Issues – Project related issues could be technical, business process, change management, resource or third party (ex: vendor and supplier) related among others. Issues could come through word of mouth, e-mails, calls and other media resulting in some of them being lost or accidentally overlooked over time. These have the ability to then spiral into major problems. An Issues log is an effective but often overlooked tool. It is a safe and reliable way for all participants to raise issues, analyze and prioritize them, track and assign responsibility and finally, follow up.
Dependencies – It is not sufficient for project activities to be correctly sequenced. Failure to clearly identify dependencies leads to waiting periods in the project lifecycle stalling its progress. This is where the Critical Path Method (CPM) comes handy and something which PMs do not make effective use of.
Ideally, a PM must possess some level of knowledge or subject matter expertise in the project work. The notion that a qualified PM can manage any sort and size of project is twaddle.


Ten Traits of a Project Manager that makes a Project a Success:
1.ensure proper and timely communication
2.effectively address resistance to change
3.use consensus and not dictatorship
4.have the ability to delegate
5.constantly engage the users
6.ensure project needs and available skills are in line
7.understand culture and work with virtual teams
8.analyze how a minor change can effect a complex system
9.conduct effective meetings which achieve intended objectives and
10.Finally, work with emotional intelligence (ex: show empathy, possess self-awareness among others).


A Special Note on Information Gathering - Central to all of this is his ability to gather information from all project sources (specially the project team) to help detail his project plan. The saying “the devil lies in the details” is most apt for a Project Plan. Extracting the most amount of information from his team members is often a challenge. A missed activity in a Project Plan could have repercussion. After several meetings, some PMs land up with a Project Plan that has say 120 activities while others could come out with one that has 180. It’s now left to you to guess which one would have a higher likelihood of success.
It needs to be understood that while a Project Plan needs to be as detailed as possible to prevent surprises, it does not give the PM a reason to micro-manage each task and hence the team. Request for high level status updates should be the order of the day.
Key Fact - It needs to be understood that any project that does not have the same Delivery Manager in charge from the agreement of the objectives to the completion of user acceptance testing and successful handover to operations is likely to struggle & miss meeting customer expectations.


7) The Project Team – Needless to say, their role is essential in the success of a Project. Ten ways a Project Team contributes to the failure of a Project:
1.During the course of the project, technology becomes the focus at the expense of business functionality for many team members including the Project Manager.
2.At times, team members struggle because of their unfamiliarity with the methodology used in the Software Development Life Cycle.
3.Participation of project members in multiple projects delineates their focus. Dragging them regularly to solve operational issues does no good either. It is important for the Project Manager to negotiate and manage the schedule of project staff.
4.No prior experience of team members lead to an inaccurate Project Plan.
5.Absence of proper and timely communication from team members between themselves and with the Business Units/Clients needs to be addressed.
6.Inability to properly manage the expectations of the PM and help him address the client’s issues leaves much to be desired.
7.Dysfunctions in a Project Team are another contributor. The five stages in developing and managing a Project Team that of Forming, Storming, Norming, Performing and Adjourning needs to be take care of.
8.Late engagement of a Quality Analyst (QA) - Failure to involve a testing team at an early stage and have them contribute to master and individual test scenarios remains a short coming. If QAs are not available early in the project for some reason, programmers should check each other’s work. Also, if programmers have to re-code a function then they should thoroughly re-test not only the function in question but all other features in the application that could be affected.
9.Absence of an IT Business Analyst (BA) - It was rated among the Top 20 jobs to pursue in 2012 by Money Magazine but unfortunately, this role has not been clearly understood thus far. For large Organizations with complex systems, the need for an IT Business Analyst arises to fill the gap of someone who knows the business well and has technical skills (ex: in a 60:40 ratio) to engage in a project that requires a strong understanding of technology. As they work more closely with the Business Units and spend their time likewise, they are in a better position to represent the Business and its needs in a Project team. Their ability to speak the Business lingo and better justify ROI for Projects makes them special. They help IT move closer to the Business and their problems. For Organizations that cannot afford a BA, the Project Manager works closely with a Super User who has functional knowledge of the Business.
10.Lack of a competent Enterprise Architect (EA) - Their role evolved with the responsibility to design replacements for old legacy systems (to understand and document the old system well and help migrate smoothly to a new system with a Service-Oriented Architecture). Today, an EA is responsible to address the increasing complexity of IT systems, deal with real Business problems and help convert Business needs to technology solutions. He fills the role of a good technical lead that has prior experience and knowledge down to the level of the specific Business area. This helps EAs successfully architect the application design. A good EA would be definitive of the framework that he would prefer to use from a myriad of options available out there (ex: a preferred choice these days is the TOGAF framework). An EA is someone who knows the many failure modes in his/her line of work. Also, the failure of an Enterprise Architecture initiative is a result of top management being unable to set appropriate Key Performance Indicators (KPI) for EAs.In Part 3 of “Making IT Projects a Success”, we will take a detailed look at challenges in IT Infrastructure Projects and some best practices.
Key Fact - A Project that has a turnover rate among key delivery staff of more than 15% p.a. is a cause for concern.


In Part 3 of “Making IT Projects a Success”, we will take a detailed look at challenges in IT Infrastructure Projects and some best practices.