Nội dung

34 Beyond Management Here is a paradox for me: we have all the pieces that management experts say we should have—like a structure, the tools, and good data—and we push the goal of customer satisfaction, but the organization is quite dysfunctional (the ERP project is a good example) and we don’t always deliver what customers want. Quite often I hear myself say “we’re in a mess.” The AB project looks like another mess waiting to happen. If there was a funny side to this, I’d put it down to Murphy’s Law, aka Sod’s Law: “whatever can go wrong will go wrong.”2 But it is more than a random act of fickle fate. Reassignments are deliberate. Someone made the decision and, presumably, thinks this isn’t just a good idea but is the right thing to do. I’m having difficulty seeing how it could be either. The way I see it, TDM is a changing assortment of projects. We have to deliver a quality product each time, on each project, and the question I’ve been asking myself is would we manage projects this way, making decisions like reassigning team members, if the customer matters like we say he does. I believe the customer’s interests are being sacrificed for something else and I’m realizing that there is more than one set of perspectives, priorities, and interests on what is the right course of action. Project teams’ priorities, it seems to me, are clearly different from management’s priorities and I’m in the middle, dealing with the fallout, and trying to work out why and what is right. The “client” view of project work In my experience the work of project teams revolves around the client even when they’re dealing with a tight budget or there is dissention in a team. That is what I see when I’m wearing a project-team member’s hat and it is quite easy to understand why they see things this way. You’re on a team because of your expertise and experience. Your work is your craft and you want to do it to the best of your ability and, while you are doing it, the client is right there, in front of you. Each project is a network of the people working together on something, like a proposal or lines of code. The network expands as the project moves from ideas to initial proposal to a product that is tailored to the client’s needs. Every inch of the way is a learning process, with people figuring out with one another what is going on, what has to be done, what others are doing, and whether they are on track. Learningas-you-go is vital to a project’s success, more important even than solving the technical problems and people spend a lot of time sharing knowledge: exchanging ideas and figuring out what is going on.3 Jeff’s journal: project work on the inside There is so much going on in a network, so many groups are working on different things, it is quite easy to lose sight of how important the client is; and I don’t mean just at the end, when it is time to deliver. All along the way the client is central. You have to engage him continuously to find out what he wants. Quite often he doesn’t know what he wants until he sees it—sees what you’re doing or what you’ve done—so you go back and forth, getting to know him, sorting out his requirements, offering advice, making changes, and working to get through roadblocks together. Over time, because of these interactions, there is a rich tapestry of information in a project network. It is made up of shared knowledge, ideas about what has to be done, views about what the customer requires, and so on. Most of this is tacit knowledge: the sort that is in people’s heads and hearts, not written into documents or stored in computer files; the sort you probably don’t know you have until you draw on your experience to explain something to someone.4 When you reassign team members in the middle of a project you rip apart the fabric of the network. That puts severe strain on the whole project and has a big impact on a team’s morale and their performance. For one thing, it drains the project of this tacit knowledge. Another part of the story is the client who gets the short straw because an under-resourced team has to scramble to complete the project at the last minute and perhaps features he wanted are missing or haven’t been properly developed. A colleague, Dawn, put it this way: When word comes down from head office, “we take shortcuts and turn cartwheels trying to complete the contract on time and on target. In the process we short-change our clients and ourselves.” Where is the customer? Figure 4.1 shows that reassigning members of a project group means something completely different when you wear a management hat. There are no customers in that drawing, because top management is responsible for the organization, which is everything inside the triangle and doesn’t include customers. (Interestingly, TDM management prefers “customer” but the project teams usually talk about “our client.”) Managing a contract means keeping your eye on dates, deliverables, and dollars, though not necessarily in that order. If someone asks where the customer fits into the picture, I’d have to say “under the base of the pyramid.” Management is at the top, work at the bottom, and the 35 Beyond Management 36 customer must be close to the work. At any rate, he is outside the triangle and outside the view and responsibilities of management. I think this is a fair assessment of how head office approaches the contractual obligations of a project. Customers don’t feature prominently in top management decisions. It is the project teams that connect an organization to its customers, but to show this I’d have to include networks of relationships that are crucial to serving customers. They aren’t in the picture because they aren’t on management’s agenda either. The organization—strategy, mission, and bottom-line—is much more real than the customer and, because these matter to management, they take priority. Customers matter, but only in the way the contract matters: in terms of costs, completion deadlines, a list of deliverables, and their bottom-line impact. It is different with project teams. They build relationships with their clients. You might say they are attached to them. It’s an emotional bond. They want their clients to be satisfied with the work they do, both to show they are good at what they do and because they don’t want to let them down. Managing a contract and providing your client with a good product are different mindsets. I’m starting to realize that there is a deep tension between the contract-is-all approach, which is how organizations are managed at the top, and the people-and-client-centered attitude of project teams [the “view from practice”].5 Putting the contract first explains why people get pulled from functioning teams and why their customers get short-changed and, because they come from different mindsets, perhaps there are irreconcilable differences between these two positions. I’m sure there really is tension between management and project teams [see Figure 4.2]. I put it down to their different interests and values but I think this is only part of the story. Management values organizational performance, while project teams value the quality of Figure 4.2 Management view Project team view “It’s the contract” • Dollars • Dates • Deliverables “It’s the customer” Do what it takes to satisfy the client TENSION Teams’ and management’s views Jeff’s journal: project work on the inside their work and these don’t mean the same thing. You can see the contract mindset in management directives and processes, which revolve around dollars and data (e.g. time-sheets). The management mindset is the one that prevails because it belongs to the people on top, in charge. Yet, to me, the idea of someone in charge and in control is really a sham. We say this is so, but it is all a pretense. We’re supposed to follow directives (like the one to pull people from the contract), as if work gets done because management directs, authorizes, or approves it. Meanwhile, we aren’t thinking about the crucial role of the project team and the whole network that surrounds and serves them. There is another side to how work gets done that is hidden. I believe the rest of the story about the tension between contract and customer is this: not seeing what it takes to deliver a quality product, we manage projects as if the other side doesn’t matter; this is why team members get reassigned, putting a whole project at risk. What is the right way to manage projects? I’m talking about the difference between how we do manage and how we could and should manage them, because customers and the work of project teams matters. TDM produces customized software, not standardized products. Our business is tailoring. We have to make sure that what we produce fits the customer properly. The devil is in knowing what the customer wants and being able to deliver it and the only way I know to do that well is through well-functioning project teams. How do we make sure project teams can do their work properly and produce good quality work? Where to from here? Is there a different way of managing projects that won’t get us into the kind of trouble the AB team will surely soon be staring at? Or, is there only one way to manage? It seems to me that a good place to start is to look at what a project team does and how they handle their work. Standard practice puts management in the role of scheduler, controller, and regulator of work, but I don’t believe the work we do is amenable to this kind of top-down control and it’s not clear to me that the kind of structure we get from management—reporting lines, regulations, systems, and standards, all symptoms of a culture of compliance—is right for the work we do. When I heard somewhere about “loose coupling,” the idea resonated with me. We don’t live in a clockwork world. “Loose coupling” seems 37 Beyond Management 38 to describe our work environment, so I Googled it. I found this on Wikipedia. “Loose coupling . . . is found in computer systems, and was introduced into organizational studies by Karl Weick. Loosely coupled systems are considered useful when either the source or the destination . . . systems are subject to frequent changes.”6 That last bit nails it for me. A lot of the work we do at TDM is subject to frequent changes. Not only that; project requirements are open-ended and ambiguous. Suppose that you are a manager and you see it as your job to create a system of tight controls, including rigid rules and complex reporting requirements, because it is what you believe managers do. But, if work is and has to be loosely coupled, the system you’ve put in place doesn’t fit and shouldn’t be there. It becomes dysfunctional. You end up obstructing people’s efforts (mine in this case), then they get confused and disheartened. That sounds to me like a fair description of what goes on at TDM a lot of the time. We try to do everything by numbers nowadays, even thinking you can manage projects based on time-sheet data. Turn a contract into numbers (dates, deliverables, and dollars) and you end up treating it as a play-book; but it isn’t.7 A contract is a broad statement of work and you have to go from there to concrete action and a specific, satisfactory result. That is usually a tricky, subtle, and, also, mysterious process. Organizing the development and delivery of an elaborate piece of software reminds me of clouds forming (and reforming) it is so loosely-defined. You can’t control clouds and you certainly can’t do it by numbers. When I look at the work we do, I sometimes wish we had a play-book, but we don’t. Sometimes I think we don’t even know what the game is. We are constantly discovering this as we go and, to top it all off, we invent and reinvent the rules at the same time, which sets me thinking . . . Part 2: how things actually work Jeff’s cloud theory A project begins with a little cloud—the initial idea. It probably isn’t possible to say exactly where and when it starts but it isn’t a directive from the top, a well-developed plan, or a request to solve a specific problem. A highly sophisticated piece of software and the incredibly complex process of creating and delivering it begin with somebody’s “good idea.” People get together and talk (perhaps it is a potential customer Jeff’s journal: project work on the inside meeting someone from new product development). Sometimes those talks go nowhere but, if they have traction, there is more talk and sharing ideas. It isn’t clear why some ideas go forward while others don’t or why a project eventually lands in our laps. So much is going on behind the scenes that what happens is more art and luck than science. Was it our marketing? What about business relationships? How did people’s motives play a role? What would have happened if our bid had been different? When things do get moving, one little conversation becomes the seed of all the work people eventually do on a project. In the end hundreds might be involved and it all begins with a few conversations—the little cloud! Based on those conversations there are more conversations. People write proposals and prepare budgets—more conversations— and they move forward. Then they do more talking (and negotiating and bargaining). Now there are lawyers, HR and contracts specialists, and consultants involved. They talk, but not necessarily to each other, and things move forward a bit more. New people become part of the process and things move forward a bit more. They write specifications, set deadlines for the different phases, do more talking and bring more people into the process, and so on. The idea that things are always moving forward is a stretch. Sometimes they stand still and nothing happens for quite a while as people deal with a setback or wait for approval. Usually there is a lot of groping around as well as moving and sometimes it seems we are actually in reverse. But with a bit of luck and because people work hard and put in long hours the cloud becomes a bigger cloud; then that bigger cloud becomes a bigger one, until the project is complete [as illustrated by Figure 4.3]. Figure 4.3 Clouds make a project Listening to people talk about work, in terms of “efficiency,” “feedback,” “cycle time,” “structures,” “performance,” and so on, you’d think 39 Beyond Management 40 they were all engineers, immersed in some or other technology. Clouds give us a totally different picture. Clouds don’t have substance; you never take in the whole because there is always the sense that there is more than you see; and their boundaries are fuzzy and ambiguous. As a picture of organizations I like this one much better. Inside an organization everything depends on where you are. The organization you see at the top—say you are a board member—isn’t like the one people see from inside the mail room, at the bottom. For the little their work has in common and the little they know about each other’s work, the board room and mail room might as well be different organizations—or different planets. The cloud metaphor helps to shake off the silly idea that an organization is a whole “thing.” Why do we waste time and money trying to get people to buy into the mission and vision statements we pay consultants to produce for us?8 There are five divisions, more than 30 departments, and who knows how many project teams at TDM. All are doing their own thing. Does the mission statement on our website, the lobby, and other public places keep these parts together and people on track, working like a closely knit family? If the mission statement isn’t there when we get to work tomorrow, will it matter? Of course not! It may actually be an improvement, particularly if it forces us to talk about what our different parts (groups and units) do and whether they support each another as needed (Melvin’s bunch aren’t supporting me or the AB team). The idea that organizations are whole is just another pretense and it prevents us from seeing what is actually going on. People and groups work by making connections. We call the connections “networks,” perhaps for good reason. There is a “net” of connections and this is where work happens (net-work–get it?). Things get done when people interact, because they interact, and while they interact. The connections matter [As illustrated in Figure 4.4] organizations are like ecosystems. We don’t know what the whole looks like, but this doesn’t matter. What counts is relationships – interconnections among parts, not the parts. Of course you can’t see these interconnections (just as you can’t tell why clouds are breaking, moving, or joining), but this doesn’t matter either. Everyone knows about them and knows how crucial they are. Jose contacts Marina. She talks to Melita who speaks to Sandile. Once they connect and talk, they are off, working; discussing a deadline, reviewing an Jeff’s journal: project work on the inside 41 Lexi “TDM” Sally The AB team “TSG QM” “Network developers” “Assurance bank” Sakkie Kehla Alice Rob Alice’s boss Bob Andre Marketing Melita Silas Development Ted Me Serge T. Government relations Marina – contracts Jose taskforce project director Sipho Melvin Federal projects division Figure 4.4 Carol IR Head office Connections make a project agenda, or trying to resolve differences. Some interactions are momentary (you call someone for advice), others could continue on and off for a few days, or possibly weeks (colleagues who create a new training program together), and some go on for months and even years (those long-term projects, or work-relationships in a stable department). [In Figure 4.4], I’ve shown some of the connections related to the AB project. If I had to describe in organizational terms what the AB project is about and how things get done, I’d talk about these, plus ones I haven’t shown. We’ve got four organizations—ourselves, AB (the client), Network Developers, and TSG QM—and people in those organizations who are working on the project. It’s their connections, as they network, that shape how the project gets done. As their manager, this is what I want to know about. Every interaction in every connection is a working relationship that influences how people work together, what they do, and what they accomplish. These are what I must keep my eye on, to see whether things are going well or badly [i.e. when there are “breakdowns”]. Our work is truly group work. No one works alone. But, the groups I’m talking about aren’t nice, neat clusters of people, with clear boundaries, who get along well because they know and respect each other’s strengths and weaknesses. Groups are made up of people from different departments, different divisions, and even different organizations. They might be working with colleagues they hardly know. This means relationships on a project are complex and potentially fragile. [As you see here] co-workers belong to separate units or organizations; they 42 Beyond Management have different allegiances; and could be competing with one another for performance bonuses. People join and leave groups all the time, so boundaries are loose and flexible—talk about loose coupling! I understand why it’s hard to make group-work “work.” People have to pool their knowledge, share ideas, and learn from one another. It’s no good if they don’t interact well or won’t communicate. If they don’t or can’t cooperate, there are all sorts of problems. It is hard to find a cohesive core group like the AB team but, when you do and they keep the project together there is no holding back. Moving people from a project is like a sudden change of pressure that blows clouds away. It breaks the structure they’ve created by fracturing relationships and/or making it difficult for new ones to form. You can’t just take a team apart and expect to put it back together again, later, like clockwork. This isn’t how creative teams function. Part 3: structure in organizing Organizing = effort + magic People do many different things on any project. Not forgetting that there are crises and crunches, the way a project comes together is actually extraordinary. So, how does it happen? In order to support project teams, it is crucial to have answers. Watching project teams at work, I’ve thought a lot about this and asked people what they do to bring it all together and keep it together as they go. What is interesting is that most can’t tell me exactly what they have done or are doing. They can generally say why they’re doing something, but a lot of what they do is intuitive. The way I see it, organizing a project is about equal parts effort—it is hard work and takes everyone’s time and energy—and magic. The work I’m talking about gives projects structure; but there is another part that’s difficult to explain yet is as important for success. It’s there, it happens, but you can’t reduce it to a formula or even explain it fully. That is why I think of it as magic.9 We recognize effort and want people to do more and give more, but you’d never know about the magic if you heard a group of HR managers talking about a pay-for-performance system. They’d be talking about incentives, outcomes, data, equity, buy-in, etc., as if this is all there is to the story. It isn’t; there is magic in every project and if we don’t see it, admit it, and try to support it (is it possible to cultivate it?) we’re likely to kill the proverbial golden goose (like pulling people off the AB team?). Jeff’s journal: project work on the inside Work emerges To me, it’s magic how things get done without overall coordination and detailed plans, when there isn’t anyone in charge. AB is quite a small project but it is mindboggling to think of what goes on. It reminds me of the old story of the three blind men and the elephant.10 You have lots of people doing all kinds of work: like marketing work, financial work, and technical work. It takes their combined contributions to build the product or provide the service a client wants, but they’re working at different ends of the elephant, on different parts. They have varied interests and responsibilities, each has his or her own perspectives, and no one knows how someone’s work fits with everyone else’s. Sometimes being inside a project team is really rough. When ideas or personalities clash there are arguments and bad feelings. But they are mature professionals and manage to organize themselves, by themselves, bit-by-bit. Another part of the magic is that, for most of the time they are working on a project, team members don’t actually know what they’re doing or where they’re going! Today’s work emerges from what has already been done and from ideas about what to do next.11 This happens from the very beginning. Remember the little cloud? A project is born before anyone makes plans. It’s in someone’s imagination: “we could really do with a software tool to aggregate and analyze our data.” Lots of conversations follow. Eventually a product is delivered. It is like this every step of the way. What do project teams have to guide them? Usually, little more than a proposal that might have been revised and restated many times, plus their emerging ideas. All the while, they’re planning, negotiating, writing, drawing, coding, and organizing to accomplish something that exists in their heads as varied and fragmented ideas. It is only late in the process, near the end, that they actually see what are working on. Until then they use their imaginations and improvise.12 Self-organizing Organizing project work is a “just-in-time” phenomenon, with team members performing an intricate dance to keep things moving and get the work done.13 The way they work is more like soccer, where play emerges in the moment as players assess and respond to what is happening, than American football, with a coach and his playbook. Team members juggle schedules so they can get to a client meeting on the 43