Documents

A Practical Guide to Project Management-Final2

Description
A Practical Guide to Project Management-Final2
Categories
Published
of 31
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  A Practical Guide To Managing Projects 1 A Practical Guide to Managing Projects  A Practical Guide To Managing Projects 2 Background Project management has become increasingly important. The skills and basic methodology have been in use for thousands of years. The Egyptians used these skills in building huge pyramids which are still in good shape after over 2000 years! Purpose of this Guide This Practical Guide is based on the Managing Successful Projects with best practice guidance but has been summarised in an easy to follow format. It should be used by practising Project Managers to help them manage their project or anyone with an interest in project management. The focus of the guide is to help Project Managers manage their projects. Being successful in project management requires more than just knowledge of project management. Project Manager can develop other necessary skills to complement. By following this effective Practical Guide, you should be able to :    Distinguish between ‘day to day’ work (i.e. business as usual) and projects      Define projects and project management    Understand some of the common jargon associated with project management    Apply relevant concepts, including dependencies in managing projects.    Manage risks in managing projects    Calculate resources you need in your projects and use them efficiently    Learn to manage a project team    Explore a few ideas in building a career in Project Management Why Project Management? ‘Operations keep the lights on, strategy provides a light at the end of the tunnel, but project management is the train engine that moves the organisation’ –  Joy Gumz 1.   Performance in organisations can be measured more effectively by measuring the outputs and outcomes of projects. 2.   Projects focus people in achieving results 3.   Change in organisations can be initiated better by initially doing projects as ‘pilots’. The results are then assessed to decide if the change, often involving more resources, is worthwhile starting and implementing. 4.   It is generally easier to get funding for projects which can deliver specific results, particularly for not-for-profit organisations which rely on funding from the public sector oor funding organisations. Why Projects Fail Research indicates that over 50% of projects either fail or they do not meet the expectations of stakeholders. We can probably all think of projects that have failed  –  perhaps processes got worse rather than better, maybe they were cancelled because of cost overruns, or perhaps systems were launched with fundamental errors.  A Practical Guide To Managing Projects 3 How do you know when  –  and why  –  a project has failed? In many cases, the reason for failure is obvious. However, the definition of failure isn't always clear: one project with a significant delay might be described as a failure; yet another, with a similar delay, might be seen as a stunning success. 1.   What is project failure? 2.   What factors cause some projects to fail? Definition of Project Failure  A project is considered a failure when it has not delivered what was required, in line with expectations. Therefore, in order to succeed, a project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case. The requirements for success are clear and absolute  –  right? Unfortunately, it's not that simple. Because the second part of our definition of success is that the project must be delivered in line with expectations. If key stakeholders agreed that a project had to exceed its initial budget, the project may still be considered a success. Likewise, if a project delivered everything that was in the detailed project designs, it may still be considered a failure if it didn't include vital elements that the key stakeholders needed. This doesn't seem fair, but project success and failure isn't just about the facts, nor is it simply about what was delivered. It's also, crucially, about how the project is perceived.   What factors cause some projects to fail? (Reasons for Project Failure) Here are some of the main reasons why projects fail:    The wrong business requirements have been addressed If your project is set up to deliver the wrong thing, it may be considered a failure even if everything is delivered on time, within budget, and to the required quality. This seems harsh. But if your project doesn't deliver what the organization really needs, this will inevitably negatively affect how it's perceived. This is why it's so important to conduct a thorough  business requirements analysis .     It's not possible to deliver the business case  If your business case can't be delivered, then you have an impossible task. To make things worse, after the business case is approved, delivery of other things then becomes dependent on your project. This makes changing your project's deadlines, budgets and expectations more difficult.    For example, once you've promised to deliver a new airport baggage management system, airlines may schedule additional flights for shortly after the system's launch, so that they can take advantage of the new capacity. If the baggage system doesn't work, or if it has major problems during testing, it may be hard to convince senior managers to allow the project to be delayed, because they will have to give up promised increased revenue.    When you write your business case, make sure you think through the project requirements in detail, and identify what's needed to ensure that you can deliver those requirements. Don't just list assumptions  –  make sure you explore them thoroughly. Review other, similar projects, so that you don't forget any major items. If you're delivering a new system, review your hardware and interface requirements. If you have major risks, include sufficient contingency resources (people, budget, and time) to manage those risks appropriately. Remember that  implementing change is hard !     Be realistic, and be ready to have some difficult conversations. For instance, your CEO may be disappointed that he can't have what he wants before the year end, or key users may say that they really need a fully featured product at the end of phase one. However, it will be a lot harder to have these conversations at a future date, when your project is in trouble! In many cases, business case documentation is written before a project manager is assigned. If you're the incoming project manager, make sure you don't simply accept these documents as they are!  A Practical Guide To Managing Projects 4 You're responsible for delivering the project, so be sure to review the business case. Validate assumptions, and identify any gaps or areas that need more detail. If difficult conversations are needed, have them now. Once deadlines, requirements, and budgets are set, expectations are much more difficult to change! Governance is poor    Few projects ever start without a  sponsor . This is the person who has identified the need for change in an area of the business, and who is committed to making that change happen. He or she plays a vital role in ensuring the project's success. A good sponsor can make a mediocre project fantastic, and a poor sponsor can delay and frustrate a fantastic project team.    The project sponsor is supported by the project's  governance bodies , usually in the form of a steering group. These governance roles are essential: they provide direction, guidance, and critical review of the project and its progress. As project manager, you're involved in the day-to-day running of the project, but governance groups can take a step back and look at the project from a different perspective. They can ask difficult questions about progress and performance. They may see things that you've overlooked. However, they can also support you by providing contacts and insights that help you get things done, and by providing political cover when you need it.    Project managers don't usually have any influence over who their project sponsor is. Sponsors either self-select, or they're chosen because of their position in the organization. However, you often have more influence over who is in your steering group. As such, if you know that your project sponsor lacks passion for the project, or if the sponsor doesn't like to say no to people who keep trying to expand the project scope, then make sure you balance this with tougher or more engaged steering group members. Implementation is poor    you deliver your project competently, you'll avoid poor implementation  –  right? Unfortunately, it's not that clear. Delivery can be complex. You need to manage risks, issues, and scope; manage your team; and communicate with stakeholders.    Delivering change is hard, and not everything is in your control. Therefore, being competent isn't enough for good implementation, but it's a good start! People lose focus on the project's benefits      Projects are based on a list of benefits that must be delivered. For example, you may need a faster customer service process, you may need to produce products more cheaply, or you may need to improve the quality of your service. These benefit statements should be refined so that they're clear, concise, and quantified.    From these benefit statements, a set of things to do is generated. For example, you may need to consult customers, redesign products, or implement a new system. The outcome of this is a  business case  document that analyses the project in terms of costs, and of the benefits will be delivered.    The project team then focuses on detailed planning, and on delivering the line items in the project plan  –  building a new system, developing training packs, mapping out new processes, and so on. At this stage, the team may forget about the benefit requirements.    This often results in a project deliverable that's well built, but doesn't provide the necessary benefits. For example, if the project plan focuses on designing and building a system, you could get a fantastic system, but one that's not being used by the business.    To avoid this problem, adopt a  benefits management  approach throughout the life of the project, and remember the need to deliver the required benefits when you're planning and delivering your project. The environment changes      This is probably the most tricky area. If the business's needs change, then your business case can become out-dated before you've actually completed the project. You may have to review your srcinal requirements and goals partway through the project to decide how to proceed, and this may result in changing the scope of your project  –  or even cancelling the project altogether!    If you're working in an environment that's changing fast, you can help reduce the risks by doing the following: Making timely decisions       –  If the project is clearly not going to be able to deliver the revised requirements, don't ignore this. The sooner you communicate this, and the sooner you make a decision about the project's future, the better . Considering smaller projects  
Search
Similar documents
Tags
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks