I received a question from someone dealing with a discrepancy between how EVM reporting has been presenting progress versus actual progress.
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Why Change Control Is Important
Categories:
Change Management
Categories: Change Management
|
Essentially, the scope and cost of the project has increased, partially through estimation problems and scope changes over time. However, it appears they are still reporting against the same Performance Measurement Baseline (PMB). The sooner you can transparently communicate with key stakeholders, the better.
It sounds to me like what should have happened is a re-baseline with all parties involved so everyone understood the reasons why and you could go get more funding now. If you are using EVM, the forcasts should have been showing a slipping SPI and CPI this whole time, in which case everyone would know there is a problem.
Josh, A rebaseline only happens when everyone agrees there has been a significant change in scope, cost, or schedule.
Scope increases should only be accepted by the contractor via a contract modification and/or formal change management process. Do you have a Change Control Board (CCB) consisting of the sponsor, key stakeholders, and project leaders? Ideally, all of these changes in scope would have resulted in a Change Request (CR) to the CCB, and once approved the Performance Measurement Baseline (PMB) is updated. This way you are only working on approved scope and your EVMS has value. That said, baseline changes shouldn't happen for estimates that were just off. They must be from CRs which are tied to a clear change in scope outside of the project's control (new customer requirements, massive unexpected procurement cost differences, new regulatory requirements, etc.)
It's always more painful the later it occurs. At this point if I were in your shoes, I'd have a CR describing every individual reason for a baseline change, work it through the CCB and manage change formally via the CCB from here on out. It may be an "ask for forgiveness" moment right now where you have to be honest and open, admit mistakes humbly, and show the plan to improve going forward.
|
Posted on: January 30, 2012 03:48 PM
| Permalink |
Comments (0)
Are You Wasting Money On Your Projects?
Categories:
Cost Management
Categories: Cost Management
|
What is the fiscal responsiblity of the project manager anyway? Are we just supposed to deliver projects within budget? Is that the extent of our responsibility? NoLook, there are plenty of ways to manage projects. Some of them involve a ton of paperwork, and some involve just what adds value to the end user. Some build in a certainty of tons of rework by planning for detailed design months or even years before development, and some plan on progressive elaboration after formulating a solid start-up plan to get a clear idea of the end goals and project constraints. Ask YourselfI challenge you and myself. Let's ask ourselves as we go about our working day to stop and think about our own activities and those of our team members. Do those activities add value? Which activities could we do without or do better. Are we getting the 'bang for our buck'. Do we run on our fuel of incoming investment dollars like a shiny new hybrid compact sedan, or a gas-guzzling Hum-Vee? And in the final analysis, does your project either 1) save money for the organization or 2) make money for the organization? Do you measure ROI in a rigorous way? If not, how can you even tell? |
Posted on: January 25, 2012 09:52 PM
| Permalink |
Comments (2)
How Important Is Learning On Your Projects?
|
Most of the waterfall based project management thinking assumes that planners know enough about what the customer wants and estimate with enough accuracy to create a huge waterfall schedule way in advance. True or False?I certainly think it's true. A good example is large, predefined releases which go into low-level details. With predefined releases we are assuming that we know how project execution will play out well ahead of time. My experience has shown me that we don't know, especially with large complex projects there are too many interfaces involved and decisions during execution that change the reality of what adds value from the customer perspective. This creates all kinds of hassles regarding which scope goes into which release, which really doesn't matter when it comes to the end customer. Unless it's going to change the timeline for which these features or capabilities are available to the end user, it doesn't really matter which release it gets pocketed into. What If?So what if projects treated validated learning, a concept from Eric Ries' book "The Lean Startup", as the primary goal of the project? What if the primary purpose was to learn through iterations and then provide what the end-user wants, as opposed to just having the delivery of certain scope on time and on budget? Could we set up a project management system in such a way that learning, validated learning, is the primary driver for project planning and execution, and still be confident that we are going to meet the projects scope schedule and budget requirements? I haven't had an opportunity to do this myself fully from end-to-end on a large project. I've only been able to implement these types of principles within a subset of a larger project. So I can't say for sure. But I have heard from many people who are implementing projects in a Lean organization, using the type of approach that I'm talking about here. What do you think about the importance of learning as a major part of your project management methodology? Deming's Plan>Do>Check>Act cycle is (sometimes) applied to PM processes, but how often is it applied directly to assessing the customer definition of value? Please discuss in the comments below! |
Posted on: January 20, 2012 09:16 PM
| Permalink |
Comments (0)
Making Big Projects Lean: Organize Teams By Function
Categories:
Lean
Categories: Lean
|
The kitchen team, bathroom team, living room team, bedroom team, dining room team, and garage team all assembled at the building site. Each was responsible for every aspect of their assigned room from beginning to end, and when they are all finished a separate construction integration team will come in to make them fit together.
What?In construction we don’t have ‘kitchen teams’ that do all the framing, flooring, plumbing, electrical work, fixtures, lighting, etc. We have specialists who do the plumbing throughout the entire structure, the electrical wiring and work in the whole building, etc. They are good at what they do and get better and better at their specialty from project to project. Imagine a different electrician wiring each room. Different teams painting each room, different doors and doorknobs, etc. Imagine if a different person ran the plumbing in each place separately, and then at some arbitrary time everyone came together to integrate all these separate plumbing subsystems. I know, it makes me cringe too. And yet this is exactly what we do on many large systems and software projects! Organize by FunctionInstead of organizing projects and teams by components or subsystems, it makes more sense to group by a particular functionality or specialty area that can be applied across the entire project. For the most part we get this right with IT support roles on projects like Systems or Database Administrators. But with development roles I tend to see organization by system, not by function. So you end up with 10 teams like a “System XYZ Team” and a “System ABC Team” etc. What’s wrong with that, you ask? A few things:
You have 5-10 different people (who usually don’t talk much) working on nearly the same thing in each subsystem. For instance, 5 different people working on their own versions of a user interface for each system, all of which will be utilized by the same team of operators (end-users). Doesn’t it make more sense to organize those 5 people as the “User Interface Team” instead? Now you get a group of people on the same team working together, learning from each other, creating a better quality product which will be more maintainable. They pick the best platform and go with it. Consistency means maintainability and a better experience for the users. Because you have a focus now on a particular functional area, you can find people who are good at that function and passionate about it. Usability is huge in my opinion, and yet it’s a discipline that gets dropped out of most projects very quickly. But with a team focused entirely on the user experience, usability can get the attention it deserves. Demos and immediate feedback (thus, learning) will go through the roof. You may be thinking we still need things like ISDs to coordinate the interfaces between the UI and system control teams, for example. I’ll argue that the need for these become fewer in number, and coupled with continuous integration through frequent, small releases, this becomes a non-issue. The teams learn the interfaces better and can improve them more readily by actually integrating and learning on a continuous basis, not from trying to interpret a specification document.
In This Series: |
Posted on: December 31, 2011 11:40 AM
| Permalink |
Comments (18)
Making Big Projects Lean: Continuous Integration
Categories:
Lean
Categories: Lean
|
Big projects have a lot of moving parts. Lots of individual teams and systems that need to interface with each other in the final product.
Many organizations have addressed this complexity and sheer number of interfacing systems by creating ‘levels’ of testing whereby subsystems get integrated into larger systems, which then get integrated with even larger systems. It’s The HierarchyThe standard hierarchical way of thinking about people and systems is a big part of the problem. This approach carries with it tremendous coordination costs and waste due to the process overhead and gap in time between a feature is originally implemented until it is fully verified and validated as being correct. These coordination costs tend to make the releases larger and larger, because much of the release costs are fixed and so more releases means a nearly linear amount of extra coordination costs. That’s how we end up with releases 6-12 months or longer in duration. Waiting for an integration milestone increases the risk of rework as teams interpret interface specifications differently, customer needs change over time, etc. Another funny (and sad) side-effect that occurs with this model is the lag between testing at the level of actually writing code versus the ‘higher-level’ tests. I’ve seen delays of as much as 6 months. Many times, the “lower-level’ development team has produced their next release before their previous release is integrated into the system. This is highly confusing for testers and end users, and when problems are discovered at ‘higher-level’ testing you are usually forced to distract the developers from their current release with the bureaucracy involved at those high level tests. Minor bug fixes that take about an hour to investigate, fix, and test end up consuming tens or even hundreds of hours collectively in meetings and reports due to the level of formality and attendees at meetings. (20 people in a meeting for 15 minutes talking about a minor bug is 5 man-hours, and usually the managers and senior engineers involved are at a much higher pay rate than the developer who fixed the bug in an hour. Scary, huh?) Make The World FlatDiscard the hierarchy.Continuous integration means that the focus of a release is a single feature (or perhaps a few) and that item of focus is what the whole team is concentrating on. The entire system from beginning to end is rebuilt and tested. Testing is as automated and streamlined as possible, and this is only feasible if your configuration management and build processes are also lean and mean. The best configuration management systems I’ve seen are capable of easy updates after approval with automated rebuilds. They allow you to make releases as small and frequent as possible, which is exactly what you want for continuous integration and making your projects as lean as possible. Feedback is nearly instantaneous. Bugs are fixed faster because developers don’t have to go back and read through their code to figure out what it’s doing. It’s hot off the presses and still fresh in their minds. Rework is avoided. End-users and testers get to try to break the system right away and see it for themselves. This decreases the amount of assumptions project teams have to make about the product from everything to major functionality of the system to minor user interface tweaks that make it easier to use. Imagine
In This Series: |
Posted on: December 29, 2011 04:48 PM
| Permalink |
Comments (0)