Beyond Management Workplace_2

34 BeyondManagement 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—andwepushthegoalofcustomersatisfaction,buttheorganiza-tion is quite dysfunctional (the ERP project is a good example) and we don’talwaysdeliverwhatcustomerswant.QuiteoftenIhearmyselfsay “we’reinamess.”TheABprojectlookslikeanothermesswaitingtohap-pen.Iftherewasafunnysidetothis,I’dputitdowntoMurphy’sLaw,aka Sod’sLaw:“whatevercangowrongwillgowrong.”2 Butitismorethana randomactofficklefate.Reassignmentsaredeliberate.Someonemade thedecisionand,presumably,thinksthisisn’tjustagoodideabutisthe rightthingtodo.I’mhavingdifficultyseeinghowitcouldbeeither. The way I see it, TDM is a changing assortment of projects. We have todeliveraqualityproducteachtime,oneachproject,andthequestion I’ve been asking myself is would we manage projects this way, making decisions like reassigning team members, if the customer matters like wesayhedoes.Ibelievethecustomer’sinterestsarebeingsacrificedfor somethingelseandI’mrealizingthatthereismorethanonesetofper-spectives, priorities, and interests on what is the right course of action. Project teams’ priorities, it seems to me, are clearly different from man-agement’sprioritiesandI’minthemiddle,dealingwiththefallout,and tryingtoworkoutwhyandwhatisright. The“client”viewofprojectwork In my experience the work of project teams revolves around the client evenwhenthey’redealingwithatightbudgetorthereisdissentionina team.ThatiswhatIseewhenI’mwearingaproject-teammember’shat 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 craftandyouwanttodoittothebestofyourabilityand,whileyouare doingit,theclientisrightthere,infrontofyou. Each project is a network of the people working together on some-thing, like a proposal or lines of code. The network expands as the projectmovesfromideastoinitialproposaltoaproductthatistailored 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. Learning-as-you-go is vital to a project’s success, more important even than solving the technical problems and people spend a lot of time shar-ing knowledge: exchanging ideas and figuring out what is going on.3 Jeff’sjournal:projectworkontheinside 35 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 continu-ously to find out what he wants. Quite often he doesn’t know what he wantsuntilheseesit—seeswhatyou’redoingorwhatyou’vedone—so you go back and forth, getting to know him, sorting out his require-ments, offering advice, making changes, and working to get through roadblockstogether. 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 drawonyourexperiencetoexplainsomethingtosomeone.4 Whenyou reassignteammembersinthemiddleofaprojectyouripapartthefab-ricofthenetwork.Thatputsseverestrainonthewholeprojectandhas a big impact on a team’s morale and their performance. For one thing, itdrainstheprojectofthistacitknowledge.Anotherpartofthestoryis the client who gets the short straw because an under-resourced team hastoscrambletocompletetheprojectatthelastminuteandperhaps features he wanted are missing or haven’t been properly developed. Acolleague,Dawn,putitthisway:Whenwordcomesdownfromhead office, “we take shortcuts and turn cartwheels trying to complete the contract on time and on target. In the process we short-change our clientsandourselves.” Whereisthecustomer? 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 trian-gle and doesn’t include customers. (Interestingly, TDM management prefers“customer”buttheprojectteamsusuallytalkabout“ourclient.”) Managing a contract means keeping your eye on dates, deliverables, anddollars,thoughnotnecessarilyinthatorder.Ifsomeoneaskswhere 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 36 BeyondManagement customer must be close to the work. At any rate, he is outside the triangleandoutsidetheviewandresponsibilitiesofmanagement. I think this is a fair assessment of how head office approaches the contractual obligations of a project. Customers don’t feature promi-nently in top management decisions. It is the project teams that con-nect an organization to its customers, but to show this I’d have to include networks of relationships that are crucial to serving customers. Theyaren’tinthepicturebecausetheyaren’tonmanagement’sagenda either.Theorganization—strategy,mission,andbottom-line—ismuch more real than the customer and, because these matter to manage-ment, they take priority. Customers matter, but only in the way the contractmatters:intermsofcosts,completiondeadlines,alistofdeliv-erables,andtheirbottom-lineimpact.Itisdifferentwithprojectteams. 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 theydoandbecausetheydon’twanttoletthemdown. Managing a contract and providing your client with a good product are different mindsets. I’m starting to realize that there is a deep ten-sion 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 twopositions. 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 Management view “It’s the contract” Dollars Dates Deliverables Project team view “It’s the customer” TENSION Do what it takes to satisfy the client Figure 4.2 Teams’andmanagement’sviews Jeff’sjournal:projectworkontheinside 37 their work and these don’t mean the same thing. You can see the con-tract mindset in management directives and processes, which revolve arounddollarsanddata(e.g.time-sheets).Themanagementmindsetis theonethatprevailsbecauseitbelongstothepeopleontop,incharge. Yet,tome,theideaofsomeoneinchargeandincontrolisreallyasham. Wesaythisisso,butitisallapretense.We’resupposedtofollowdirec-tives(liketheonetopullpeoplefromthecontract),asifworkgetsdone because management directs, authorizes, or approves it. Meanwhile, we aren’t thinking about the crucial role of the project team and the wholenetworkthatsurroundsandservesthem.Thereisanothersideto howworkgetsdonethatishidden.Ibelievetherestofthestoryabout 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 awholeprojectatrisk. What is the right way to manage projects? I’m talking about the dif-ference between how we do manage and how we could and should manage them, because customers and the work of project teams mat-ters. TDM produces customized software, not standardized products. Our business is tailoring. We have to make sure that what we pro-duce 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 makesureprojectteamscandotheirworkproperlyandproducegood qualitywork? Wheretofromhere? Is there a different way of managingprojects 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. Standardpracticeputsmanagementintheroleofscheduler,controller, and regulator of work, but I don’t believe the work we do is amenable tothiskindoftop-downcontrolandit’snotcleartomethatthekindof structure we get from management—reporting lines, regulations, sys-tems, and standards, all symptoms of a culture of compliance—is right fortheworkwedo. WhenIheardsomewhereabout“loosecoupling,”theidearesonated with me. We don’t live in a clockwork world. “Loose coupling” seems 38 BeyondManagement 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 destina-tion...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. Notonlythat;projectrequirementsareopen-endedandambiguous. 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 report-ing 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’tfitandshouldn’tbethere.Itbecomesdysfunctional.Youendup obstructing people’s efforts (mine in this case), then they get confused anddisheartened.Thatsoundstomelikeafairdescriptionofwhatgoes onatTDMalotofthetime. 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, sat-isfactory 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 itbynumbers.WhenIlookattheworkwedo,Isometimeswishwehad aplay-book,butwedon’t.SometimesIthinkwedon’tevenknowwhat the game is. We are constantly discovering this as we go and, to top it alloff,weinventandreinventtherulesatthesametime,whichsetsme thinking... Part2:howthingsactuallywork Jeff’scloudtheory Aprojectbeginswithalittlecloud—theinitialidea.Itprobablyisn’tpos-sibletosayexactlywhereandwhenitstartsbutitisn’tadirectivefrom thetop,awell-developedplan,orarequesttosolveaspecificproblem. A highly sophisticated piece of software and the incredibly com-plexprocessofcreatinganddeliveringitbeginwithsomebody’s“good idea.” People get together and talk (perhaps it is a potential customer ... - tailieumienphi.vn