Application integration is the process of exchanging data between two or more business/application systems. Integration between software applications presents a unique set of challenges. The author describes seven best practices that can be applied to any integration effort, large or small, to improve delivery results.
Why did PMI make Project Integration Management the first knowledge area instead of the last? Doesn’t integration happen when everything else is complete? Read on while we continue our series that shows why getting in physical shape is much like getting ready to write the PMP/CAPM exam...
Using continuous testing, one can immediately detect problems in code — before it’s too late and problems spread. Using a clever combination of tests, tools, and techniques you can tell right away when there’s a problem and it’s easiest to fix. The author uses a case study to illustrate the benefits of continuous integration (CI) and how it leads to better quality control (QC) and quality assurance (QA).
Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. How can we act more productively?
If your project involves external resources in any capacity, then you are dealing with one or more outsourcing arrangements. This article gives some strategies for mitigating common obstacles for managing outsourced projects.
In the journey to PMP fitness, you have taken three decisive steps. But many PMs have not had the opportunity to participate in a suite of courses where most knowledge areas are explored from a combined approach of PMI theory and real-world application. While this can put you at a real disadvantage, it’s still possible to be successful. In out latest installment, we cover Project Integration Management.
If we want better projects, we need to be better at our project management. But is consistency and formality the answer? Is demanding adherence to a common process what is required to get to “better”? The evidence here is mixed.
One team or a handful of teams may be able to deliver small systems with agile, but large complex systems require teams of teams to deliver significant features. How can companies benefit from “the team effect” at scale?
The Olympic rings are five intertwined circles that represent the elaborate and complex Games. Similarly, project managers can bring five rings of discipline together to manage very complex projects. Each of these rings builds upon the other--and they give the project manager a taxonomy by which to manage Olympian efforts
How well do mega-projects get managed in comparison with normal projects? Given the size, the scale, the visibility and the sensitivity of these projects, would it be reasonable to assume that they are managed more formally and more effectively than “normal” projects? Reasonable: possibly. Correct: sadly, no.
"Big" is somewhat defined in the eyes of the beholder. Beyond sheer size and mass, what makes big projects so daunting? Certainly as a project grows in size and scope, a number of things increase along with it--each adding complexity and risk to the effort. While there is no foolproof way to eliminate the risks associated to big projects, there are some things you can do to reduce those risks.
The attached workbook is useful for these many projects out there where no costing data can be used--or is not available--so the classic Earned Value Technique cannot be applied. It provides not only a progress tracking mechanism but also effort based project forecasting based on the above consideration.
Behind every successful project is a rock-solid, detailed project plan. This template defines every aspect of your project. The final product can be used to make what you are doing clear to all project stakeholders.
This is a high-level example of a Project Charter for implementing a methodology, but the structure and approach will work for many projects. This example is heavy on risks and assumptions, light on budgeting, role descriptions and conflict resolution.
Timing is everything, even in project management. The key to a successful project is to use JPACE--that is, to Justify, Plan, Activate, Control and End it the right way. This Microsoft Project plan will help you do just that.
This checklist is designed to assist in the identification of areas where projects are strong or weak in project management. Ideally, the health check should be carried out at regular intervals, especially at major decision points to ensure no loss of expertise and progress in addressing areas of weakness.
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.
While there are some subtle differences in closing a project with a party or a wake, a carefully defined checklist will help with either ending to the project. This checklist should be defined early on in the project and communicated to everyone who will have input into the checklist at the end of the project.
Your project plan will determine how good (or bad) life will be for you and your team over the course of the project. A good project plan uses the proper inputs, addresses good planning practices, and is positioned for ongoing use through the life of the project. Put sufficient effort into the plan and double-check it against a guideline, such as this checklist.
This template outlines a classic Project Charter with a focus on project definition and strategic ties. Risks and stakeholder needs are covered, but not in granular detail. It is appropriate for fairly low-risk projects where the goal is to get everyone on the same page up front.
The HEADWAY large project plan is a work breakdown structure in MS Project containing links to detailed instructions and resources on gantthead.
"People are always blaming their circumstances for what they are. I don't believe in circumstances. The people who get on in the world are the people who get up and look for the circumstances they want and, if they can't find them, make them."