50 Top IT Project Management Challenges

Premi Shiv, Premanand Doraiswamy

• Publisher: IT Governance Ltd
• Year: 2012
• ISBN:
  9781849283434
• Topic: Computer Science
• Subtopic: Desktop Applications
• Index: Computer Science

A concise guide to the top 50 IT project management challenges and how to overcome them.

Project management forums highlight many of the challenges project managers face. Unclear requirements, scope creep and undefined roles are well-trodden issues that can derail a project. Other challenges are less obvious, often more subtle, but equally destructive.

This book offers a focused and concise summary of 50 challenges facing today’s IT project manager. Broken down into 50 easy-to-digest chapters, the authors draw on years of practical experience to outline these challenges, and offer useful tips and advice on how to deal with them.

Condensing much of the information and advice found in project-management-related books and discussion forums, this book enables readers to be better equipped to respond to key project management challenges; it  is, therefore, an ideal reference for anyone involved in IT project management.

 

CHALLENGE 1: UNCLEAR REQUIREMENTS

In a poll recently conducted by us in a recognised project management forum, the majority of the project managers acknowledged that unclear requirements are, without a doubt, a top challenge for their projects.

Starting with vague requirements is like heading off on a journey without knowing your destination. You are dealing with the unknown.

The common practice amongst us is that we just bow to pressure from senior management. We accept the ambiguous requirement specifications and proceed with our estimations. Eventually, those projects get delayed, costs are at least doubled, the client’s quality expectations are not met, and, in the end, the project manager gets the blame.

What would be the best way forward in this situation? Let’s begin with brainstorming some ideas.

Can you challenge your senior management and not commence the project until all of the project requirements are clarified? Is that a feasible idea? Probably not.

You cannot delay the commencement of a project based on the excuse that the project requirements are unclear. Business and IT departments would not want delay in their time to market, or increased costs from extended timescales. In this case, what is the best way forward?

Make assumptions visible

You can start on the project with some tactical assumptions based on your and your team’s experience, the best knowledge on the domain. You can then build your estimates based on these assumptions. The key point is to ensure that these assumptions are visible to your project stakeholders, by recording them in the standard project documentation.

Log a risk

Record in your risk register that your estimates are based on unconfirmed assumptions. Assign an owner and include a resolution target date. Once the action owner confirms your assumptions, if they happen to be wrong, you can re-estimate with a well-defined change management process. By doing this, you are getting what you want, while managing your stakeholder expectations with tact.

Even if the action owner doesn’t confirm your assumptions, despite continuous follow up from you, and on project delivery/testing your assumptions are proved to be wrong, you will have the facts and appropriate project documentation to cover you from the blame game.

Discuss when in doubt

Arrange regular discussions and requirement analysis meetings with stakeholders. Discuss any issues and get clarification. When in doubt, the best practice is to ask.

Be agile

You can go for the iterative development life cycle and start with what you have, reaching out to clients for their feedback at every stage of development. Use this feedback to fine-tune the requirements, thereby hashing out all uncertainties. This will lead to further requirements, due to the holes you have discovered. Describing the functional design, implementing business rules, and getting clients’ sign off, would cut down on the assumptions.

Use the ‘cone of uncertainty’ – narrow down the cone of uncertainty by defining what you can and cannot do. This eliminates any deviation towards the end of the project. As you progress towards the target and tighten the specifications, you can update your estimates and lessen the uncertainty.

You can point out the variance graph to management at any time, indicating the vague requirement as the cause.

Go phased

Don’t try to build the whole ship in one day. You cannot expect a product owner, or analyst, to envision the entire product/project during the design phase. Similarly, you cannot build a whole application at once. The best way is to do it in phases. Divide the project into different phases and attack the unknowns. When difficulties are broken into smaller chunks they are much easier to address.

Define good and bad

Analyse and separate out the good and bad requirements. Document what you assumed to implement. This will be the best feedback you can provide to your business and clients, and it encourages clearer requirements in the future.

Buffer on estimates

Last, but not least, have a buffer on the estimates, as per Hofstadter’s Law, to account for requirement changes.

CHALLENGE 2: MISSED REQUIREMENT

Nothing is more challenging for a project manager than a situation where, after successful project go-live, users complain that there is a requirement gap in the final product. Missing a requirement causes bad press for the project and project manager, and can damage the reputation of the organisation. In addition, there is an extra cost to fix, or the requirement to include in the next release, due to the rework around coding and testing.

Based on the criticality of the missed requirement, there could be a significant loss to the organisation in terms of business benefits.

The following ideas can assist in reducing the impact of this challenge.

Manual workarounds

Check if there are any manual workarounds in the system which can temporarily silence the users. In the meantime, the team can work on delivering the missing requirements. For example, if there are reports that users expect to be system generated, this may be achieved with a few support people manually exporting the data to an Excel^® report. This would be a good interim arrangement.

At the same time, you can try the following to avoid mishaps.

Track and trace

This idea is inspired from the logistics of an organisation, such as DHL. DHL provide a reference number to every client with their shipment. The client can use this reference number to track where their shipment is, and if/when it reaches the desired destination.

We can apply the same logic in this case, where you can reference each item of your detailed project requirement and start tracing it at every major deliverable. For example, to check how a requirement is managed in your design documents, in code, in test scenarios, in test scripts, and in deployment plans, and to track it through the entire life cycle.

This will give you the confidence that all the requirements are now covered as part of delivery.

Client workshops

Facilitate workshops between your clients and your technical team. This encourages two-way communication and helps explain to your clients how the requirements are managed in the product. At the same time, it gives the client the opportunity to question any trivial requirements, which might have been missed in your team’s presentation.

CHALLENGE 3: DELAY IN DOCUMENT APPROVALS

In an average complex project, the number of deliverables/documents created should range from 50-100. It is a mammoth challenge to get all these deliverables organised, shared with reviewers, reworked based on review comments, approved by clients, and baselined in the document repository. If you have experience working in a matrix project organisation, then you will be aware that it is far more complex. The resources allocated to you might be shared, have different line managers, have their own priorities, or not be fully allocated to you. These are a few of the many challenges.

Many project managers’ pet peeve is that they usually get the review comments on the final day of the review period. So either you have to delay the project to work on the review comments, or extend the work timings to accommodate them.

The following ideas can assist with managing this challenge efficiently.

Prepare a RACI for each deliverable

For each deliverable of the project, prepare a RACI (responsible, accountable, consulted and informed). A RACI is a tracker which shows who is responsible, accountable, consulted and informed of a deliverable/document. You can share a RACI with the relevant people, so they are aware, up front, of their responsibilities. You can even share the timescales for each and every deliverable.

Block reviewer’s/approver’s calendars

The most efficient way to get the reviewers/approvers to review your document is to block out time in their calendars for the review workshop. In these workshops, your team can walk through the document with the reviewer and make amendments at the same time. At the end of the workshop, make sure the approver signs on the dotted line.

CHALLENGE 4: SCOPE CREEP

Scope creep is one of the top five reasons why a project can fail. To define scope creep, let us consider a construction company which is building a house for a client, with a well-drafted plan. During the client’s visits to the house, new items keep getting added to the plan, for example, building a wardrobe, an extra sink, more power outlets than planned initially, etc. The engineer implements the changes without documenting them on the plan and, once the house is built, there are several issues faced by the construction company:

• The house layout in the plan, and what has been built, do not match.
• The company incurs loss because the extra items bought are not charged back to the client.
• The extra electrical outlets cause a voltage trip, or load shedding, resulting in more costs to the construction company.

Who is to be blamed here? Is it the client, who has not adhered to the process of putting forth their request in the correct manner? Is it the construction team, which has taken the request without informing the construction company, or documenting the changes? Is it the construction company, which has not put forth the process and trained their resources for situations like this?

Does this sound familiar to you? If you apply this in an IT project management scenario, clients request extra features, or changes in features, directly of the team, without checking the end-to-end implications.

Scope creep causes increased cost, effort and time. However, you cannot go back to the business owner and ask for additional money, since you have not followed any process, or laid out any plans to manage this.

How can you manage this challenge?

Put change management processes in place

All changes requested by business/clients/users are to be requested officially, and recorded in the relevant project documentation. This will enable impact/cost/timescales analysis to be completed. Based on approval from the budget owner, work on change requests can then be completed. It is important that all team members are aware of this process.

Learn to say ‘No’ and teach to say ‘No’

Although it is beneficial to meet all client demands possible, and to keep the relationship in good health, there comes a time when you, or your team, can’t be the ‘Yes man’ any longer. There are some clients who will try to get things done quick and dirty. They will not follow any process, and will directly approach you/your team. It is important to be assertive and say ‘No’ in such situations.

CHALLENGE 5: UNCLEAR RISKS AND ISSUES

It is important for a project manager to track project issues, risks, assumptions and dependencies. Sometimes it is very challenging for a project manager to keep them up to date, as well as log them in the appropriate place. It is a very common problem to have the project issues and risks logged/reported int...

Table of contents

• Cover
• Title
• Copyright
• Contents
• Introduction
• Challenge 1: Unclear Requirements
• Challenge 2: Missed Requirement
• Challenge 3: Delay in Document Approvals
• Challenge 4: Scope Creep
• Challenge 5: Unclear Risks and Issues
• Challenge 6: Project Infrastucture Issues
• Challenge 7: Service Introduction Challenges
• Challenge 8: Undefined Project Dependencies
• Challenge 9: Project Methodology
• Challenge 10: Handling Escalation
• Challenge 11: Time-driven Projects
• Challenge 12: Undefined Roles and Responsibilities
• Challenge 13: Post-live Support Uncovered
• Challenge 14: Project Infrastructure Delivery Delayed
• Challenge 15: Unclear Quality Criteria
• Challenge 16: Unstructured Project Costing
• Challenge 17: Resource Utilisation
• Challenge 18: Revision of Estimates and Timescales
• Challenge 19: Vendor Quality Issues
• Challenge 20: Wrong Assumptions
• Challenge 21: Unclear Business Rollout Approach
• Challenge 22: Project Cancellation
• Challenge 23: Project Operational Issues
• Challenge 24: Undefined Project Critical Path
• Challenge 25: Time and Cost Issues
• Challenge 26: Overestimation of Projects
• Challenge 27: Unmanageable Plan
• Challenge 28: Overspent Projects
• Challenge 29: Vendor Payment Milestone Issues
• Challenge 30: Poor Source Code Quality
• Challenge 31: Process Interference
• Challenge 32: Project Colour Coding
• Challenge 33: Project Go-live Failures
• Challenge 34: Project Prototype Failure
• Challenge 35: Critical Team Member Absence
• Challenge 36: Insufficient Schedule Information
• Challenge 37: Insufficient Domain Knowledge
• Challenge 38: Insufficient Technical Knowledge
• Challenge 39: Delay in Starting Project
• Challenge 40: Missing Teamwork
• Challenge 41: Performance Appraisal Conflicts
• Challenge 42: Project Synergy Missing
• Challenge 43: Stakeholder’s Micromanagement
• Challenge 44: Project Status Report Issues
• Challenge 45: Vendor Contract Confusion
• Challenge 46: War with PMO
• Challenge 47: Ambiguous statement of Work
• Challenge 48: Ambiguous Non-functional Requirements
• Challenge 49: Too Many Meetings
• Challenge 50: Troubled Project Rescue
• ITG Resources