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)
Making Big Projects Lean: Responsive Management
Categories:
Lean
Categories: Lean
| Management of projects is an important role, however in many cases it is overrated. We project managers tend to exaggerate our discipline to the extent that observers may conclude we feel management is the goal of projects. That our role is the most important one. How arrogant. Unfortunately, this leads to several troublesome trends I’ve seen time and time again on projects of all kinds. It creates roadblocks to progress which are codified and made a part of the project organization. And yet we think we are helping our teams get things done. PlanningProgressive elaboration can be utilized to great benefit even within a waterfall approach to managing projects, but it doesn’t seem to happen well as often as it should. Even within ‘agile’ projects managers will approach planning with a hubris allowing them to believe their crystal ball magically allows for detailed plans way out into the future.The world doesn’t operate that way, unless you are cranking out very similar products over and over again, for the same end-users. And yet large projects commonly go through a design phase in which requirements are elicited, detailed Work Breakdown Structures are drawn up, rather detailed designs are created, etc. In aerospace, we have a several planning milestones as a standard process way before teams actually start doing real work:
This process can take a long time (years in some cases) and only afterward do development teams start working on releases of the systems. Each of these releases are generally fairly large, primarily (in my opinion) because of the high overhead and coordination costs involved due to what is mostly waste; busy work that does not add value to the end products. Months and years can pass between the time requirements are elicited, designs are made, and something is actually implemented. And yet managers are surprised and disappointed when designs change before and during the course of implementation. Change ManagementChanges happen constantly on projects. Going back to the arrogance of thinking we can successfully plan in detail way in advance, many managers see change as a bad thing. This includes project managers, sponsors, executives, etc.What is typical about change management implementations, especially on large projects?
Configuration ManagementPrimarily, the problem here is confusing configuration management with change management. Many organizations see this as the same activity, the same discipline. It’s not.Configuration is about controlling what version of a product is deployed in a specific environment. This applies to documentation, code, COTS packages, hardware, and anything else that is part of the products being produced or the tools for getting the project done. The same criticisms of change management apply to configuration management as well on large projects. Many times the method for configuring an item in a baseline or in a specific environment (a specific test environment for example) is so long and painful that we tend to like large releases so we don’t have to deal with configuration management that often. Risk ManagementRisk management is important, and having a system in place to encourage the identification and proactive tackling of risks is critical -- especially on large projects. However just as noted with the other management disciplines, on large projects risk management tends to be a behemoth time-suck in which more time is spent over the course of months on valueless pieces of busywork that could have been better spent actually mitigating or avoiding the negative risk.We spend months on templates, automation, fancy prioritization schemes, etc. When it comes down to it, all you need is to define the risk in a sentence, figure out how to address it if it’s worth it, and go do it. 1. Define: [Given] {condition} [there is a possibility] {risk event} [resulting in] {consequence} 2. Decide: Mitigate/Accept/Avoid/Exploit -- How? 3. Take Action Know Your Place, ManagersThese management practices and more exist for the project team and stakeholders, not the other way around. They are not ends in and of themselves, they are part of the means to the end only. Especially on large projects, these disciplines can sprout little fiefdoms whereby leads or managers over these areas believe the project exists for them and not the other way around. This leads to initiatives to create a slew of standardized templates, convoluted processes that try to manage every exception to the rule, and a separation from reality as team members focused on these management areas disassociate themselves with the people doing the real work of producing products for the end users. In my experience, if you view your role as a manager to facilitate the ability of the people involved with actual product creation (developers, end users, team members), it’s much easier to contribute real value to the team. |
Posted on: December 27, 2011 09:16 AM
| Permalink |
Comments (0)
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: |
Posted on: December 26, 2011 08:57 PM
| Permalink |
Comments (0)
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.
Posted on: November 30, 2011 07:33 PM
| Permalink |
Comments (7)
