Making Big Projects Lean: The Series
Categories:
Lean
Categories: Lean
|
Over the years I have worked with teams on large systems projects in various industries. These have all tended to be managed with ‘traditional’ project management practices including a waterfall development cycle.
I have observed some key areas for improvement in these projects. They tend to have a lot of waste. This manifests as long delays between value-adding activities, rework, and local optimization instead of system-wide improvements. It also comes in the form of lots of busy work that doesn’t add any real value to the final products. PMOs in general are a big contributor of non-value added busy work in my experience and in my opinion. They’ll spend months revising management plans, project processes on flowcharts, etc. -- usually in a detached way from the actual work that is being done and thus the actual value being created by the project teams. We’ve all seen it -- a new process document comes down from on high and all the developers and other team members groan as they try to figure out how they can appear to be in compliance with this nonsensical new process and still manage to get some real work done. They tend to undervalue the creativity of project team members.The single most valuable resource on any project is the project team members. Big projects with waterfall development in particular tend to view people as ‘widgets’ or ‘resources’ that are interchangeable and simply get assigned tasks to get done. People are treated as being outside the systems...people are seen as operators of processes instead of part of the processes themselves. This is a big mistake. When we see people as operators of cogs in a machine simply producing output, we are leaving a great deal of untapped potential on the table. In my experience not only do people want to do good work they can be proud of, they want to contribute intellectually and creatively to the project as a whole. This includes ideas for improving product creation, management and development processes, and a whole host of other attributes that go on in any project. They demand cutting corners.Milestones and inertia drive project decisions and the focus tends to be on requirements verification, not validation. Delivery to specs is more important than ensuring the specs actually meet the needs and desires of the end users. The tendency for this to happen increases as a function of time. The cost of making changes increases over time, and because most large projects with a waterfall approach neglect the importance of continuous learning and feedback as being integral to everything they do, many changes are discovered as necessary late in the project and then need to be negotiated down or completely away. Of course as we all know, customers and end-users don’t really know exactly what they want until they see it. They have a vague idea in the beginning, and most large projects codify this vague understanding into requirements that are increasingly resistant to change as time goes on. In the end, you have a product which may meet most of the end-user needs but you’ve probably had to negotiate and sacrifice those needs to avoid costly rework. Another phenomenon that is common to see is cutting corners on activities like testing and validation processes -- settling in the end for ‘good enough’. They force multitasking on the project teams.There is usually little to no focus on, well, focus. Project team members and project managers are always trying to juggle ten tasks at once, and when things fall on the floor we put our fire-fighting hats on. I know you’ve seen it just as often as I have -- the project has a handful of things in work simultaneously, and team members are bouncing back and forth. They start lots of things, but those items only get completed when management decides they are the ‘red alert’ of the week. This holds especially true for critical resources with a specialized skill. They get bombarded from all directions to help with this little thing, that little thing. They end up working from home at off hours to get their ‘real work’ done when they aren’t being disturbed every ten minutes. About This Series
In This Series: |
Project Management Is Not About Getting Work Done
|
He was doing everything he had been taught to manage projects effectively, and yet it seemed as if more time was being spent on rework and just getting things done. A fellow colleague was doing well. Her projects were not only going well, but she and her team seemed much less stressed. "I'm in trouble here, I need to know your secret. Can we chat?" he asked. "Of course," she replied. The struggling project manager laid out his problems, one after the other. "I'm working my tail off, and so is my team. Yet every day is like putting out one fire after another. We are always re-working something because it wasn't what the customer really wanted. And all of our tasks seem to take so long, especially when I compare my team to yours. Heck, even updating a document seems to be a monumental effort. My team is very skilled, just as good as yours. What am I doing wrong?" "You want to know what I think?" she asked. "Yes! Tell me!" he replied with exasperation. "You are focused on getting work done." "Aaaaand? Isn't that what I am supposed to do, get things done?" "No. That shouldn't be your goal. You should be adding value." she replied. "Oh come on! What's the difference?" he whined. "Work which does not add value is wasted, and non-valuable work usually ends up causing even more waste work. Stop looking at what your team is doing as a collection of tasks. Start questioning what is adding value from the customer's perspective. If it doesn't add value, why are you doing it? Also, start seeking out waste and eliminating it. Time lags between steps on an individual feature or item is a form of waste. It takes your team longer to update documentation because they have to go back and remember what they did with their code in order to make the updates. The longer it takes for anything to go from initial design to being delivered to the customer, the more waste you incur and the less value your customer gets." "I never thought of it that way" he said. "Think about it. Observe your processes in action and you'll start to see what I mean. Well, I've got to run, but it's been nice talking with you." she said with a wave as she walked away. He thought about her words for a moment. Immediately, his mind was inundated with examples from what his team had been doing just in the last week which fit her definition of waste perfectly. "Oh crap" he thought. "We have got to do something about this. Now!" |
A project manager was struggling deeply with his project.Sub-Optimize Your Way To Failure
|
Or rather, been reminded of it. Sub-Optimization SucksThe only way to acheive a truely lean organization or even a lean project is for the entire value stream to be bought into lean thinking. Because of this fact, senior leadership in any organization must be fully supportive and invested in moving an organization to lean and agile thinking and process. My teams are gaining clear benefits from the methods we've implemented with Kanban. However, because we are the only teams running this way, the benefits are also very limited. BlockedFor example, in some cases my team members need external validation from other teams before we can move a particular feature forward in the value stream. When those external parties are not bought into lean thinking (single-piece flow, limited WIP, continous deployment) they can very quickly become a block, causing a bottleneck in the value stream. Pushing For ChangeSo, I am trying to develop interest from the other teams we interface with. Who knows, maybe I'll be successful in 'converting' them. Perhaps not. Even better, I'm formulating plans for a method of convincing senior leadership that for our next program, a lean/agile approach is superior to our waterfall SDLC. We'll see. Wish me luck. |
I've realized something lately.
EVM - Earned Value Tutorial For Iterative Planning
Categories:
Earned Value Management
Categories: Earned Value Management
|
What level do you track earned value for your projects? Too high is a problem, and trying to decompose work packages prematurely is problematic too. So how do you get the best of both worlds? Here's how. I suggest you view this in 720 HD, full screen so you can see everything in the tutorial clearly. Note: Around 5:30 you'll notice in Step 3 I mis-labeled the last column. It should be PV (Planned Value) and not EV (Earned Value).
|
Master Project Scope -- Project Pain Reliever
Categories:
Scope Management
Categories: Scope Management
