If we want better projects, we need to be better at our project management. The question that remains, however, is this: Is consistency and formality the path to get there? Is promoting and demanding adherence to a common process what is required to get to “better”? Here, the evidence is mixed.
Making a transition from what you’re currently doing to an effective agile process is a project in itself--but it can easily be worth it. Let’s look at what we can gain by adjusting our approach--our concluding installment looks at interpreting requirements and tracking progress, and offers some further caution and advice.
Governance happens in projects all the time, and a well thought-out governance process can be a powerful project tool. In this article, we will examine why governance is necessary, where governance is most effective and how we as project and program managers can use governance to powerful effect.
It doesn’t seem to matter what methodologies are used--success is not a guarantee. While eyes always turn to the PM for blame, isn’t it time we examined why another significant party should also be sharing that burden?
Managing issues on a project takes strategic planning and a little finesse so that issues do not turn into show stoppers. Do you have an issue management plan that can handle any problems and still keep the project on track?
An application has been bolted together piece by piece, and it’s threatening to break any day. It’s now been handed to the PMO with the mandate to try and modernize it--and make it a tool for today that can truly act as a hub for other tools without alienating the current user base. So what does the PMO do? Read about a voyage into (potential) salvation.
All project failures are related to miscommunication of requirements. And it's the requirements that define the purpose, function and value--the business requirements--that are the biggest culprit as they are especially hard to define.
You won’t get the right benefits unless you start with the right scope. As project managers are increasingly asked to become involved in the business side of project execution, many elements they previously didn't have to worry about are now becoming relevant.
Teams work best when they are empowered to self-direct and given freedom to self-organize. Yet striking the balance between providing this autonomy with responsible project oversight can be tricky. We want to create empowered teams, but we also need to know if the project is going awry and when to intervene. A great source for creating empowered team environments can be found in the prescriptive process of PRINCE2.
Creating a work breakdown structure for the project and refining it until it can be used as the pattern for the project plan may seem like overkill for some projects, but the WBS can help create a schedule that fully supports the work of the project.
The hero of the movie John Carter can teach project managers something about scope and stakeholder management (super powers optional...and we promise you won't have to relearn how to walk due to the change in gravity...).
Large-scale change of enterprise-level architecture and infrastructure presents a challenge, especially in today's networked world. Enter agile project management. In our concluding installment, we look at successful architecture and design from history, explore the challenges that come with the principles of evolutionary architecture and design--and identify a short list of evolutionary design principles.
One of the scope management steps that can help to ensure that the WBS is as effective as possible in controlling the project’s scope is routinely ignored as unnecessary. But verifying your scope up front can save a lot of pain later.
Simply put, scope is the size of the project. But there’s more to it than that!
This checklist will assist you in minimizing scope creep, schedule extensions and project failure by evaluating whether the initial requirements are complete. This 5 page series of requirements attributes, quality checks, and examples provide a thorough review of what you plan to do.
The change request form should be used to formally initiate a request for change to a project. Types of change requests you can initiate by using this form include changes to scope, timeframes, deliverables, resources, milestones and expenditures.
Change is bound to happen. Make sure that you handle it correctly by following the proper procedures. This form will help you cover all your bases so change doesn't have to mean big surprises or project disasters.
This simple change request form will keep you mindful of what the proposed change is and the impact it will have.
How do changes get recorded, analyzed and approved on your project? This document contains guidelines for these procedures and more.
The statement of work (SOW) encompasses the goals, scope, deliverables, cost and schedule estimates, stakeholder roles, chain of command and communication guidelines for a project. Learn how to put a quality SOW together by studying its components.
Assess the scope, impact ranking and criticality of each business change required to implement a particular application package.
This procedure describes the process of testing software code or products by the test team. It documents the procedure for the entire testing cycle: generating test plans, scheduling tests, conducting tests and reporting test results. This procedure applies to new development, as well as major and minor releases, including customized solutions delivered to customers.
This Powerpoint presentation is a high-level view of the basics of planning and defining scope.
Use this form to capture the what, how and why of your proposed project change and to get sign-off from the brass.
This tool is designed to create service level agreement information for a justification or similar document. It is most useful for IT organizations that are too small to have a Project Management Office, but can use better control over linking project service level agreements with business objectives.
Are you intending to develop a project? You need a project notification sheet.
This document outlines the Business Scope, which is a description of the area of the business to be supported by the application package, including the specific business activities to be supported, the business objects to be managed and the organizations and sites to be supported.
Who's on first? What's on second? Don't know who's on third? When it comes to your project, you need to have this information at your fingertips. Use our definition of a project status report to make sure your team members provide the right information to the project manager.
|