Over the past decade, I have witnessed the life and sometimes untimely death of many information technology (IT) projects, including data migrations, custom development efforts, third-party tool implementations and system retirements. Each endeavour has had various levels of complexity, but one common denominator: an end. How the project manager gets to the end in the story land of information technology folklore tends to be either a happily ever after fairy tale or a forlorn recollection of punctuated, grim nightmares! The take-away is that there can be — and generally is — a fine line between perceived IT project success and failure.
Without espousing one project management framework over another, most would agree that traditional assessments of project success typically include some measure of timeliness financial metrics and a checklist of requirements that have been satisfied. Governance through universal knowledge areas such as risk, scope, time, cost, communication and quality management provides standards that hold the project manager accountable for project performance. This observation, however, begs one peculiar question:
Can a project rank favourably in traditional assessments, yet still be classified as a failure?
The answer when applying project management theory is commonly “no.” The answer in actual practice is absolutely “yes.” Veritable project success extends beyond the technical and tactical into the practical and strategic.
The conundrum for the project manager is determining how the end of a software development project is really measured, technically and practically. The project manager must balance the accepted technical, traditional quantifiable assessments and the practical, influential human assessments; the subtle human assessments unsurprisingly guide the overall perception.
I have found that the balance is achieved when the following L-I-N-E items are considered:
In Robert J. House’s writings, we see leadership defined as “the ability of an individual to influence, motivate, and enable others to contribute toward the effectiveness and success of the organisations of which they are members”. I subscribe to House’s leadership definition. Management, particularly in project management, is “getting things done through other people”. Leadership (strategic, practical) and management (tactical, technical) are not synonymous, in my estimation!
How can a project manager demonstrate leadership and effective management?
• Be a Chameleon: Foremost, know your leadership style. The culture of the organisation will influence how effective your individual leadership style is. Recognise your innate tendencies toward autocracy, consultation and/or consensus building and how those bode in your organisation or with your specific project team. In Dennis Slevins’ view, “the key to successful leadership is knowing what your dominant style is and being able to modify that style depending on the contingencies of the various leadership situations that you face”.
• Participate on the Front Line: Ensure that you, the project manager, are really functioning as the project pilot, or co-pilot depending on the roles of the technical lead or executive sponsor. This participation shows the project team that you are engaged in the project, aware of its nuances and actually invested in the outcome.
• Exhibit Thought Leadership: Consult on various development approaches and project management methodologies. Smartly use methodology as a guiding principle and framework- not the end-all-be-all. The subject matter expertise and flexibility underscore the pilot role and directly contribute to the effectiveness of the project team. To these, add executive-level thinking, in terms of vision, controls and execution.
• Anticipate the “Gotchas” and Mitigate the “Yeah Buts”: No one has a crystal ball, affording perfect information. The project manager, though, can use various facilitation techniques and planning sessions to proactively draw out potential “gotchas” and drill down into the “yeah buts.” This approach contributes greatly to efficiencies in downstream project activity.
Implementation and Integrity
Through a series of custom software development efforts, I have learned that success is more evident when the project manager draws a line between the project management and software development life cycles and, more specifically, isolates the implementation phase. This separation is necessary to maintain a sense of accountability. This way, the technology and development teams have primary responsibility for the development life cycle, the project manager has primary responsibility for the project life cycle, and the business owners have primary responsibility for the implementation.
The keys in the implementation phase would be the application configuration and data integrity. Although the technology and development teams can partner in the implementation effort and make sure the delivered system is compatible with the infrastructure (operating systems, network communication, accessibility, performance), it is the end user’s responsibility to ensure system usability. Furthermore, poor data quality will give the appearance of a faulty system, when the system could indeed be stable. To foster application and data integrity, use a qualified business analyst to confirm application configuration and scrub data. This will minimise false or “invalid” system issues.
Noise and Negotiation
I have found that user perception of success is the subtle but influential human assessment that gets the IT project to the “happily ever after” or yields the terribly grim nightmare! These thoughts are fuelled by laundry lists of system and project issues, valid or invalid. This “noise” lends to the water cooler opinions that diminish user confidence, in both the project and project manager.
How can the project manager foster user confidence?
• Know Your Audience: Assess the information needs of the project stakeholders and constituents. Knowing the specific informational needs helps the project manager to develop both a standard form of project communication and relationship currency. The project manager must “work the room.”
• Control the Noise: Recurring defects diminish user confidence, but the squeaky wheel and water cooler opinions do much more damage. Work diligently to identify and calm user concerns by getting to the root cause, tracking issues and then developing an actionable plan for resolution. This is also important with scope and change management. Frequent changes highlight poorly gathered requirements. Negotiate fervently to maintain the project scope and minimise change items, unless the direction has changed drastically. In that case, it really is time for “the end!”
• Communicate Early and Often: The project manager must marry organisational culture with practical leadership style-not necessarily project management frameworks-to deliver valid, timely project facts. Regular status reports minimise surprises and proactive communication builds confidence by keeping users informed.
Effectiveness and Expectations
One sure way to draw a bold line between project success and failure is old-fashioned effectiveness, perceived and actual. In some organisations, the project manager performs multiple roles, namely as the project manager, business analyst and technical lead. The competencies required for each role are vastly different! For example, a project manager manages time, cost and resources. A business analyst, however, manages requirements, processes and data analysis, as another example. A project manager who is not an accomplished business analyst, but yet expected to perform as such, will indubitably be dubbed as ineffective. Can you hear the squeaking? The same can be true for other shared roles.
How can the project manager manage expectations and show effectiveness?
Succinctly, clearly define roles and responsibilities. Separate the project manager, business analyst and technical lead roles. Each has a distinct set of competencies and value to add to the project. Document and widely communicate these roles and expectations.
Perception is reality and information technology projects are no exception. Yes, an on-time, under-budget project environment with weak leadership, questionable integrity, filled with noise and poorly managed expectations will definitely lend to perceptions of failure. The strategic and practical project manager, though, can walk a straight and bold L-I-N-E to success!