Encontre seu próximo livro favorito

Torne'se membro hoje e leia gratuitamente por 30 dias.
50 Top IT Project Management Challenges

50 Top IT Project Management Challenges

Ler amostra

50 Top IT Project Management Challenges

avaliações:
5/5 (1 avaliação)
Comprimento:
120 página
1 hora
Editora:
Lançado em:
Feb 28, 2012
ISBN:
9781849283434
Formato:
Livro

Descrição

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.

 

Editora:
Lançado em:
Feb 28, 2012
ISBN:
9781849283434
Formato:
Livro

Sobre o autor

Premi Shiv is a quality assurance specialist with 7 years’ experience in IT processes and management solutions. With an optimistic approach and organisational skills, she has carved a niche in quality assurance.


Relacionado a 50 Top IT Project Management Challenges

Livros relacionados
Artigos relacionados

Amostra do Livro

50 Top IT Project Management Challenges - Premi Shiv

you.

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

Você chegou ao final desta amostra. Inscreva-se para ler mais!
Página 1 de 1

Análises

O que as pessoas pensam sobre 50 Top IT Project Management Challenges

5.0
1 avaliações / 1 Análises
O que você acha?
Classificação: 0 de 5 estrelas

Avaliações de leitores

  • (5/5)
    Excellent book and crystal clear in grouping the challenges and its consequences