Information Technology (IT) projects are usually run by project managers who use processes such as scope, schedule, budget and quality management to get the job done. These skills are indeed prerequisite to success in completing a project, but other things are needed to deliver complex information technology projects in today’s fast-moving pressure cooker environment.
What do IT project managers need to do in order to be successful? This article examines key challenges to successful delivery of information technology projects, and gives tips, strategies and risk mitigations that can be used to structure and manage a project successfully.
A project is set in motion to achieve a result such as a business objective. A custom web application may be written to improve the productivity of a company’s workers. Enterprise resource planning software may be rolled out to consolidate a company’s data and streamline workflow and processes. Servers may be consolidated to achieve cost savings.
Fundamentally, a project changes an aspect of the organization of a business. A number of people have a stake in how such changes are implemented: managers may look for better productivity or higher sales; users of the software would like ease-of-use and time savings; internal auditors could be interested in security, adequate reporting and adherence to accounting and other standards.
Projects fail when the stakeholders aren’t aware of the details of what the outcome will be, or don’t agree on measurements of success after implementation. As a project manager, some of the keys to success include being clear on who the stakeholders are and working with them to agree at a detailed level on what the outcome of the project will be and how success will be measured. This can be done in a variety of ways.
First, scope baselines must be documented, and agreed to by the stakeholders.
These baselines include detailed requirements, visuals of how screens and reports will look, and descriptions of business rules, data, and process flows. The baselines include the details of interfaces to other systems, report design, data conversion mapping, application security, and application logging and audit requirements.
They also include descriptions of software and infrastructure architecture and the decisions related to how these will be designed. Non-functional requirements such as system performance, scalability and maintainability may constitute a baseline.
Once requirements are in place, estimates must be made for performing the work required to realize the objectives.
There are different estimating methods including ballpark or order of magnitude estimating; top-down estimating based on rules of thumb, metrics, or past project experience; and bottom-up estimating, by identifying and estimating each task to be performed. Researching this subject will yield additional tips and techniques.
Estimate granularity will vary depending on project size and the needs of the organization, but should be linked to how the outcome will be measured. Estimates are not simply numbers of months, weeks, days or hours, but are also assumptions upon which such numbers are based. For example, the length of project phases and the entire schedule is one of the assumptions.
One reason projects do not meet their schedule objective is because the project milestones are set too aggressively.
If the business dictates the dates by which a project must be completed, the project manager can do some work to identify the probability of success, and negotiate scope changes if the probability is low that the project can be completed in the requested time frame. How can the likelihood of success be calculated? A tested rule of thumb is that an IT project is unlikely to be successfully delivered if the schedule in months is less than the square root of estimated person-months of effort.
For example, if the estimated effort is sixty-four person-months, a schedule of less than eight months is unlikely to be achievable. If the date is unmovable, it is better to reduce the scope and related effort needed, rather than attempting to bring too many personnel to the project and perform too many simultaneous or overlapping tasks.
When beginning a project, the project manager must understand the budget and work to assign personnel to the project, such that their costs and estimated effort line up with the budget for labor.
If there are other costs such as software, network or hardware, making sure at the outset that these things can be procured for the allocated costs, and who will supply them and when, is key to successful delivery. If planned costs are not mapped to expected costs at the beginning of the project, a budget overrun will be a strong probability.
The other consideration when staffing the project is the type of information technology project, and obtaining people experienced in this type of project.
If the kind of project is new to everyone or almost everyone on the project team, the risk of failure is large. Only by finding staff who have done it before and know the pitfalls for the target project type will be able to guide the rest of the team to a successful conclusion.
Another tip for project managers in achieving an on-time and on-budget project is to include contingency in the estimates – effort, schedule and budget contingency. Unfortunately even when this is done, the project manager may allocate the contingency into the initial project plans, and the contingency is lost—it will be used no matter what. To manage effectively, the contingency must be held by the project manager for unexpected complexities or risks.
A best practice is to allocate hours of effort to each project team members excluding project contingency. In other words, team members understand that they are to deliver the project in the estimated hours without contingency. The project manager is then able to allocate hours to overtime, or to add time to the schedule if necessary, out of contingency, and still be within the approved budget. Explaining and documenting the baselines for stakeholders should be the basis both for testing and acceptance of the IT system, as well as the basis of formal changes to scope.
Expectation management goes hand in hand with good project governance.
It’s critical for the project manager to structure project governance and communications to continuously convey what is happening on the project, and to resolve issues and make decisions at the appropriate levels.
Best practices for a successful information technology project include the naming of a business project sponsor and a steering committee composed of information technology and business management personnel, as well as the project manager. The project sponsor should have a big stake in the outcome of the project, and have the time to work with the project manager to make decisions and resolve project issues.
Expectation management doesn’t happen only at the beginning of the project: it is continuous. In order to do this, a monthly calendar of meetings should be set up. Examples of this include steering committee meetings, team status meetings, software vendor meetings, infrastructure readiness meetings, issue and decision-making meetings, financial control meetings, and deliverable review meetings.
Meetings can waste productive time if they are not focused well.
For example, team status meetings are not served well by team members each discussing their own progress in detail. Instead, it’s better to focus on following up action items and solving issues, and on messages from the project manager to the team on external news and events. Formally documenting project issues and action items, with named owners, is essential to successfully managing progress, so that no one is in doubt about their responsibilities. If team members know they are responsible to resolve an issue or carry out an action and that they will be held to account at a subsequent meeting, they will be more likely to take action.
Similarly, steering committee meetings should be focused on bringing high level project status to steering committee members, identifying which project areas have a green or positive status, and which areas have a yellow or red negative status and need attention. The steering committee can then zero in on those areas which need issues resolved and decisions made so as not to hinder progress.
The ability to meet the project schedule is completely dependent on the ability to have issues resolved and decisions made quickly. The project team is held back by such issues and pending decisions. Resolution and decision-making unleashes a team to make progress. One of the project manager’s key tasks is to relentlessly work with issue and decision owners to move these forward.
Once requirements and scope baselines have been agreed, a key problem on many IT projects is the inability to effectively manage change.
Requests for additions or changes to requirements or other scope baselines should not be agreed by code developers or architects, or even the project manager without a formal process.
A best practice is to implement a decision request process, where decisions are documented, together with their rationale and alternatives, and what their effect will be on project budget and schedule. The business sponsor or a group of business-area subject matter experts then review and approve or reject such requests. For approved decisions which affect scope, budget or schedule, a formal project change request should be approved by the project sponsor.
The project manager then has control over project changes, and can incorporate approved changes to the project baselines including requirements, budget and schedule. In order for this to be effective, everyone with a day-to-day role on the project must be aware of how scope will be managed.
(click here to read the second part of this article).
Brought to you by PMLink.com | Author: Miguel Ylareina.
Have you joined the PMLink community yet?
Membership is entirely free!
Comments