tag:blogger.com,1999:blog-24562644902301332772024-03-13T08:11:11.405-04:00Software ManagementTraits of good software development managersThe Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.comBlogger41125tag:blogger.com,1999:blog-2456264490230133277.post-91048773781236559072016-10-04T20:03:00.001-04:002016-10-04T20:13:09.055-04:00Challenges and Surprises<div class="separator" style="clear: both; text-align: center;">
<a href="https://2.bp.blogspot.com/-tEDKKAh9OAI/V_RC1lMSeuI/AAAAAAAAAEA/WzQki__GIyUIMu5jx8yrxfeX2WnZGCc6wCLcB/s1600/Manager.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://2.bp.blogspot.com/-tEDKKAh9OAI/V_RC1lMSeuI/AAAAAAAAAEA/WzQki__GIyUIMu5jx8yrxfeX2WnZGCc6wCLcB/s320/Manager.jpg" width="320" /></a></div>
Just read an enlightening Reddit post on the other side of management. It is easy when you are rank and file to think that your bosses are bozos. However sometimes they are dealing with a lot of hidden issues that they cannot tell you about.<br />
<br />
<br />
There are laws and politics and other shenanigans going on at the mid-management level. Kind of makes you want to stay away from management positions. Check out what one cranky system administer turned <a href="https://www.reddit.com/r/sysadmin/comments/55k4lj/being_a_manager_is_hard/">manager</a> has to say about the subject.<br />
<br />The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-7199994515492253212014-06-30T16:22:00.002-04:002014-06-30T16:22:21.744-04:00Tracking Actuals<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-zP474Ljthq0/U7HGBlH3kUI/AAAAAAAAADc/s4H1qinj4qc/s1600/PM.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-zP474Ljthq0/U7HGBlH3kUI/AAAAAAAAADc/s4H1qinj4qc/s1600/PM.jpg" height="316" width="320" /></a></div>
Right now we produce estimates for all changes we make for the system. It helps us customer determine how many changes they can afford each year. We are supposed to use the estimates to determine a development schedule.<br />
<br />
I am surprised that the estimates are actually pretty reasonable and reliable. After all, the guys who do the work create the estimates. I think there is a problem on how the estimates are being used. If an estimate for a change comes out to 80 hours, you cannot schedule the thing to be done in two calendar weeks.<br />
<br />
Nobody works eight hours a day on a change. There are interruptions and other activities going on. I would hope that management 101 dictates that you use some percentage of your resources' time to estimate progress toward using up the hours from an estimate. Ha. Maybe nobody else heard of this novel idea.<br />
<br />
Currently we are adding the tracking of actual hours worked. We track how many hours we spend each day on which tasks. That will give us a clear realistic picture of how many hours of the workday are spent on the changes we produce. You would think that with this information, plus accurate estimates, one could reliably predict our project schedule.<br />
<br />
Then again, I may be expecting too much.<br />
<br />The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-35123087413063995442013-04-23T10:52:00.000-04:002013-04-23T10:52:07.632-04:00The Naive Manager<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-st3OMMbTmVw/UXafAKP6ewI/AAAAAAAAACY/8Ti9nsNs5Tk/s1600/Naive.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" dua="true" src="http://3.bp.blogspot.com/-st3OMMbTmVw/UXafAKP6ewI/AAAAAAAAACY/8Ti9nsNs5Tk/s1600/Naive.jpg" /></a></div>
I recall a fun software project I was working on around 15 years ago. We got the latest development tools. There was a number of great problems to solve. As usual, schedule estimation was a joke. This became evident when I started coding. I did some back of the napkin estimates to see how I was progressing. Sure I was knocking out all kinds of functionality. But I was way off track.<br /><br />
So I visually mapped out my pieces of the system on a white board. Then I graphically showed what I thought I needed to complete. There was still a long way to go. I showed the project manager. He said we would somehow make up the slips. LOLWUT? I did not care too much because I was having fun writing all this new code.<br /><br />
Eventually you need to pay the piper. When the date for delivery came and passed, we were still nowhere near a state to ship. We got the order to halt that project not too long after that. They brought in outside teams to assess the situation. They switched out to some outside teams to do more management. I jumped ship shortly after that.<br /><br />
The only real thing that caught me off guard was out project manager acting surprised when we missed the delivery. There was no way we could deliver given our rate of progress. This was evident to me. And I was a noob. Perhaps this was all part of some elaborate show. All I know is when I see management tendencies like this, I know utter failure is near at hand.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-72869283526989718232010-05-25T17:29:00.002-04:002010-05-25T17:33:43.909-04:00Remote Management<a href="http://2.bp.blogspot.com/_k7QkXMqfxAs/S_xBZisRmcI/AAAAAAAAAB0/5c-QRe7nGdY/s1600/Remote.jpg"><img id="BLOGGER_PHOTO_ID_5475323154040723906" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 304px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/S_xBZisRmcI/AAAAAAAAAB0/5c-QRe7nGdY/s320/Remote.jpg" border="0" /></a>These days team are split up geographically. How does a good manager cope with this challenge? Start by putting your expectations in writing. This is advised even if you have local employees.<br /><br />Next you should offer a bonus to those who finish their tasks ahead of time. There should be some incentive to stay on task when you are physically away.<br /><br />I hear that you should also have a short talk on a daily basis. This is like the daily team <span class="blsp-spelling-error" id="SPELLING_ERROR_0">standup</span> meeting. Personally I hate these. They seem like a waste of time. I find that they usually are never short.<br /><br />Require your developers to have a predictable work schedule. Even if they are at home in their pajamas, they should still be working regular hours. Finally put some short milestones in the schedule. This also applies to local workers. It allows you to detect problems as early as possible.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-43931279058338837252010-04-12T17:45:00.003-04:002010-04-12T17:46:54.217-04:00Do Your Best<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_k7QkXMqfxAs/S8OUf2DGaQI/AAAAAAAAABs/7y8_Gnh5mSw/s1600/Mistake.gif"><img style="margin: 0pt 10px 10px 0pt; float: left; cursor: pointer; width: 290px; height: 267px;" src="http://3.bp.blogspot.com/_k7QkXMqfxAs/S8OUf2DGaQI/AAAAAAAAABs/7y8_Gnh5mSw/s320/Mistake.gif" alt="" id="BLOGGER_PHOTO_ID_5459370448108546306" border="0" /></a> <p class="MsoNormal" style=""><span style="font-size: 10pt; font-family: "Arial","sans-serif";">We were looking to hire some developers about a year ago. We went through a lot of candidates. It was important to get the right fit. There is so much domain knowledge to pick up on the job. Therefore we don’t have time for people to pick up the tech knowledge as well. You got to know our technologies already.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 10pt; font-family: "Arial","sans-serif";">During our interviewing process, a manager from another group approached our big boss. He had a <span class="blsp-spelling-error" id="SPELLING_ERROR_0">dev</span> that was working for the company but did not have a project. From one big boss to another, there was a request to put this guy on our project. I was asked whether the guy could make any contributions.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 10pt; font-family: "Arial","sans-serif";">This guy’s resume was not a good fit. However I determined we could have him do some work. One would think some work it better than nothing. Big mistake. It turns out the guy was not happy with the transfer. He did not like our project. He wanted to improve his career by learning hot skills. Our project is filled with legacy technologies.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 10pt; font-family: "Arial","sans-serif";">Fast forward one year. This new guy we acquired on our team is just not working out. He can’t or won’t complete any of his tasks. We are constantly reassigning his work to other developers because it needs to get done. Last week was the final straw. We were late on a delivery because his part was not done. So we split his remaining work. After everyone else finished up, the guy could not even complete his lessened workload.<o:p></o:p></span></p> <p class="MsoNormal" style=""><span style="font-size: 10pt; font-family: "Arial","sans-serif";">I told my manager that we need to deal with this situation now. It was affecting morale. I myself was tired of doing my own hectic job as well as doing some of the lackey’s work. Plus I was getting extra tasks to plan how we could deal with his inadequacies. All of this could have been prevented by sticking to our guns and demanding we have a good fit before we hire anybody new on the team.<o:p></o:p></span></p>The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-71474122388104673532009-12-17T16:12:00.004-05:002009-12-17T16:15:30.152-05:00Mythical Man Month Wrapup<a href="http://2.bp.blogspot.com/_k7QkXMqfxAs/SyqeuBRtWPI/AAAAAAAAABk/1k2KFqBUfBw/s1600-h/Mythical.jpg"><img id="BLOGGER_PHOTO_ID_5416316015320324338" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 253px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/SyqeuBRtWPI/AAAAAAAAABk/1k2KFqBUfBw/s320/Mythical.jpg" border="0" /></a>Today I want to finish writing about some gems I read in The Mythical Man Month. One quote <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">that</span> rings true is that "authority comes from accomplishment". You got to earn it.<br /><br />Here is some more guidance that we do not practice on our system. You should put the documentation right into the code. I am not sure if that is the same as saying your source code is the documentation, or whether you should add a lot of comments.<br /><br />Do you want high developer productivity? Then focus on quality. In fact, quality is the single biggest factor which determines whether the team shall succeed.<br /><br />P.S. Do nightly builds. It will increase your quality.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-24650576466763922392009-10-27T21:01:00.003-04:002009-10-27T21:07:11.210-04:00Keeping to Schedule<img id="BLOGGER_PHOTO_ID_5397449951479732530" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 285px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/SueYIkrmGTI/AAAAAAAAABc/8ZG1sJWdErk/s320/Schedule.gif" border="0" />I continue with some more random thoughts related to keeping on schedule during a software development project. The best design is one that plans for future change. And know this, there will be change.<br /><br />Here is a crime. Managers often think their best staff members are too valuable to simply write code. That's nonsense. Yeah you might have a guy that does a lot of design. But they will get stale if they do not have hands on practice.<br /><br />Beware when developers fix bugs under duress. The result will be more new bugs. To prevent problems in the first place, you should do a test on your <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">specification</span>.<br /><br />When you are marching towards a deadline, you will almost never be able to make up day by day slippage. So how can you keep on track? You need developers with hustle. That means they just don't try hard. They try harder than needed. I want people like that on my own team.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-71882993841314812022009-10-18T18:10:00.002-04:002009-10-18T18:15:55.088-04:00Design Implication<img id="BLOGGER_PHOTO_ID_5394066027936308914" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 263px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://4.bp.blogspot.com/_k7QkXMqfxAs/StuSeTIlXrI/AAAAAAAAABU/er5BcTsz03E/s320/Design.jpg" border="0" />A small team <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">consists</span> of 10 developers. Any projects that are non-trivial will need more manpower than a small team. However many people can actually get in the way during the design phase. You need an architect to be in charge or the design. Otherwise you will get a design that lacks unity.<br /><br />It would be optimal to hire a large team of programmers after the design is done. This is the way construction jobs work. However it is not always feasible to ramp up developers quickly during the <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">implementation</span> phase.<br /><br />Since we are speaking about design, here is a worthwhile quote. "The second system is the most dangerous one ever designed." That is because the designer will have the tendency to <span class="blsp-spelling-corrected" id="SPELLING_ERROR_2">over design</span> everything. This is detrimental. A good designer must learn to leave out a lot of good ideas that just don't fit into the solution.<br /><br />Next time I will discuss writing and programmer productivity. We still have a lot to cover before fully understanding the Mythical Man Month.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-31843716620695706322009-10-13T01:34:00.004-04:002009-10-13T01:37:41.907-04:00Brooke's Law<img id="BLOGGER_PHOTO_ID_5391953769659834690" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 281px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://4.bp.blogspot.com/_k7QkXMqfxAs/StQRYr3nIUI/AAAAAAAAABM/XoGxVPoqvAM/s320/Brooke.bmp" border="0" />You can get in trouble if you try to arrange your <a href="http://susops.blogspot.com/">software development</a> schedules to match a customer's dates. This will only lead to false schedules. False schedules in turn cause evil death marches.<br /><br />Once you fall behind the schedule, there is usually no way to recoup the loss. Brooke's Law states that "adding manpower to a late project makes it even later."<br /><br />On choosing developers to work on a project, you might think that you want senior <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">developers</span>. However some research has shown that performance does not correlate with years of experience.<br /><br />Next time I will focus on the effect of team size.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-79654791468392206672009-10-08T20:00:00.003-04:002009-10-08T20:06:08.585-04:00Problems with Projects<img id="BLOGGER_PHOTO_ID_5390383446070752322" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 255px" alt="" src="http://1.bp.blogspot.com/_k7QkXMqfxAs/Ss59L0oxdEI/AAAAAAAAABE/pJYpvfGtN2s/s320/Problem.jpg" border="0" />The odds are against the team when they try to develop a system. It can be compared to a big pit. You are most likely to get stuck and never return. The design becomes obsolete before you even start coding.<br /><br />Most projects fail due to time constraints. A big factor is poor estimation techniques. This is especially true for the time allotted to test. You really should leave half the time for unit and integration testing. Another problem stems from computer programmers being unreasonably optimistic with there estimates.<br /><br />Programmers are not all to blame. They often discover what they do not know during the implementation phase. There goes the <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">estimates</span>. Managers are also notoriously bad at monitoring the progress of the schedule. Here is the memorable point from the Mythical Man Month. If you add people to a late project, the result is <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">counter intuitive</span>. Adding people actually makes the project later. More on this strange effect next time.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-9920034000862106092009-10-07T22:26:00.003-04:002009-10-07T22:30:59.982-04:00Types of Projects<img id="BLOGGER_PHOTO_ID_5390049958381735090" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 230px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://4.bp.blogspot.com/_k7QkXMqfxAs/Ss1N4SLzzLI/AAAAAAAAAA8/k-bMUI8Thh8/s320/Myth.jpg" border="0" />One person can bang out a little program in no time. Why can't we do the same for bigger systems? To find the answer, let's consider some items more complex than a little program.<br /><br />A programming product is the next level up from a program. This product must have documentation. It also needs to be developed so any developer can step in and maintain it. These extra constraints mean it will take three times longer to develop than writing a little program.<br /><br />Next up is the programming system. It contains multiple programs which communicate with each other. Developing such a beast takes three times longer than a programming product.<br /><br />Finally we have the programming system product. This one cost even more in terms of development effort. You can quickly get to a level of complexity where the development might be problematic.<br /><br />Next time I cover some issues that come up when you try to work on a programming system product.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-45502453914041418392009-10-07T00:28:00.002-04:002009-10-07T00:32:29.762-04:00Mythical Man Month<a href="http://2.bp.blogspot.com/_k7QkXMqfxAs/SswZCs_184I/AAAAAAAAAA0/2qcn__A4Oug/s1600-h/Mythology.jpg"><img id="BLOGGER_PHOTO_ID_5389710388285010818" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 241px; CURSOR: hand; HEIGHT: 320px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/SswZCs_184I/AAAAAAAAAA0/2qcn__A4Oug/s320/Mythology.jpg" border="0" /></a>I finally got around to reading The Mythical Man Month. This key text has been around since 1975. I actually read the 20<span class="blsp-spelling-error" id="SPELLING_ERROR_0">th</span> anniversary additions. There were a few updates. But most of the advice still holds true today. Amazing.<br /><br />The book was written by the gentleman who managed production of the IBM OS/360. It is actually a collection of essays that the author penned. The OS/360 system was no walk in the park. There were late deliveries, more hardware requirements, higher costs, and low performance. I guess the hard lessons learned helped educate the author.<br /><br />This text requires a lot of discussion. So I will spread out my talks about it over quite a few posts. First we need to define a couple terms used by the author. These include programming products, <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">systems</span>, and system products. Let's start there next time.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-8447084041991375892009-06-23T16:58:00.000-04:002009-06-23T16:59:30.050-04:00Bad Manager<img id="BLOGGER_PHOTO_ID_5350630457260745938" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 250px; CURSOR: hand; HEIGHT: 230px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/SkFCDVFppNI/AAAAAAAAAAs/BMxMAZN_rdw/s320/Manager.jpg" border="0" />How do you spot a bad manager? I read a whole article on the topic. Sure it was a humor piece. But many of the tendencies rang true. I guess I have worked for a lot of poor managers. Haven’t we all? I thought I would share some of these are they are precious.<br /><br />One such trait is that a bad manager is a vacation policeman. In other words, they are a vacation <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">Nazi</span>. You have to fight just to get one day off from work. On the flip side, they never say no to more work. They don’t do resource balancing. They commit you to more work that means you must work longer days and the weekends too.<br /><br />Bad managers are overly concerned with their physical appearance. This is because they cannot stand on their merits. They need other ways to look good. Bad managers spend all day in Microsoft Project. This software is not inherently evil (unless you hate Microsoft). However you will accomplish nothing by trying to perfect a schedule in a project plan.<br /><br />You can spot a bad manager because all they contribute in meetings is recording action items. You only hear from them when they need clarification on an action item. Weak. Bad managers are good a blaming others. How else do you think they get away being slackers? Finally a bad manager will jump ship even before the ship sinks. Why should they stick around when they know the project is doomed under their lacking <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">skill set</span>?The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-80437018116573946682009-03-13T16:17:00.003-04:002009-03-13T16:18:29.294-04:00Priorities<a href="http://2.bp.blogspot.com/_k7QkXMqfxAs/Sbq_dWYsfgI/AAAAAAAAAAk/73_TQ4bFZUQ/s1600-h/Priorities.gif"><img id="BLOGGER_PHOTO_ID_5312769221383192066" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; WIDTH: 320px; CURSOR: hand; HEIGHT: 300px" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/Sbq_dWYsfgI/AAAAAAAAAAk/73_TQ4bFZUQ/s320/Priorities.gif" border="0" /></a>We are a little short handed on the software development team. The workload is increasing though. Things were getting just too crazy at work this week. We have production trouble tickets to attend to. We just released some new functionality to our customer’s acceptance test team. They are generating trouble tickets as well. Finally we have new features to implement. My head was turning with all of this work on my plate.<br /><br />I put out a call for help. What I asked my team lead and manager was the relative priority of these tasks. The manager set a definite order of priorities from top to bottom. Then seeing how we had a number of high priority items, had me and the other key members of the team divide and conquer the list. The result was a less stressful environment. There is still a lot of work to do. But at least I am not getting killed.<br /><br />These types of management tasks should have been done already. You need to either conduct resource balancing to ensure people are not over worked, or set priorities and let the low priority tasks slip. I would think that a proactive manager would attend to these tasks,. But I am not against encouraging this get done. After all, I am directed affected by the chaos otherwise.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-67486174338411630722008-09-15T17:30:00.002-04:002008-09-15T17:31:12.588-04:00Risk Management<a href="http://2.bp.blogspot.com/_k7QkXMqfxAs/SM7UBOdFbUI/AAAAAAAAAAc/0JOW76wleh0/s1600-h/Risk.jpg"><img id="BLOGGER_PHOTO_ID_5246363733458251074" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="http://2.bp.blogspot.com/_k7QkXMqfxAs/SM7UBOdFbUI/AAAAAAAAAAc/0JOW76wleh0/s320/Risk.jpg" border="0" /></a>I read a blog entry by Glen <span class="blsp-spelling-error" id="SPELLING_ERROR_0">Alleman</span> entitled “Risk Management is How Adults Manage Projects”. From the title, I get the impression that Glen has been on some projects that lacked adult supervision. The sad thing is that it sounds familiar. Glen had a lot to say about risks that hit home with me. I figured I would review some of his thoughts, and share some thing I learned after reading his blog.<br /><br />You cannot hope that things will be done in software development. Estimates from developers are usually random. You need a risk management process, as well as a risk management plan. The factors involved include cost, schedule, and performance. If you do not mitigate risk, you are already failing.<br /><br />Now I have been on some software projects which lacked risk management, and they turned out fine. That may have been luck. I have also been on project with both risk management plans and processes. However many of those project failed terribly. Therefore I would not say that the presence of such a plan does not guarantee success.<br /><br />Perhaps you need to do risk management correctly. The first project I was with that bombed had a risk management plan. However it was taken straight out of Risk Management 101. And it was mostly lip service to impress the customer. I will say that the customer was not impressed when the project fell apart and was deeply behind schedule when they needed it delivered.<br /><br />I have been on other disaster projects that had huge risk management plans. They did a little more than provide lip service. There were processes that tracked some top risks. However the mitigation plans were totally lacking. This too resulted in huge failure. <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">Embarrassing</span>.<br /><br />Some people who commented on the original blog entry referred to the <span class="blsp-spelling-error" id="SPELLING_ERROR_2">DoD</span> handbook. I can say that I never heard of such a thing. So I researched it on the web. The official name of that document is MIL <span class="blsp-spelling-error" id="SPELLING_ERROR_3">HDBK</span> 1908B. It covers early risk reduction through prototyping. It defines risk as a “possible loss of function and/or degradation in performance”. There is a lot more to this handbook. I just skimmed it today. It might be required reading for managers.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-20658869986464927402008-09-13T21:18:00.002-04:002008-09-13T21:26:54.273-04:00Lead By Example<a href="http://3.bp.blogspot.com/_k7QkXMqfxAs/SMxnC9U1d6I/AAAAAAAAAAU/VrpU3BLZY8Y/s1600-h/3.jpg"><img id="BLOGGER_PHOTO_ID_5245680966499137442" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="http://3.bp.blogspot.com/_k7QkXMqfxAs/SMxnC9U1d6I/AAAAAAAAAAU/VrpU3BLZY8Y/s320/3.jpg" border="0" /></a>As the author of the <a href="http://susops.blogspot.com/">Software Maintenance</a> blog can attest, a great <a href="http://susops.blogspot.com/2008/01/project-management.html">Project Manager</a> will lead the troops by example. Developers often need to stay late due to strict schedules. This is accepted as part of the business. One would think that the project manager of such a developer would want to stay late as well. It does not matter whether the manager has any real work to do. There is something to be said about being in a tough predicament together.<br /><br />Merely staying late does not immediately qualify you as a good project manager. A truly exceptional one will manager a project such that you normally do not have to stay later. However there are often circumstances beyond the best intentioned manager's control. So at the minimum you should be willing to stick around or pull the all <span class="blsp-spelling-error" id="SPELLING_ERROR_0">nighter</span> if your staff is doing the same. Otherwise the staff will be asking themselves why they should be making the sacrifice when you are not willing to do the same.<br /><br />This principle is a specific case of the general one to lead your troops by example. You can make all the speeches in the world. However if your actions betray your words, even simpletons will see through your hypocrisy. Step up to the plate. Roll up your sleeves. Stay in the trenches with your developers. They will take notice.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-88175514813057631502008-07-15T16:29:00.000-04:002008-07-15T16:30:59.487-04:00No MiraclesOur development team migrated our code to use new development tools this year. The install package and build scripts had to be modified. Our customer decided to perform a functionality test to ensure nothing got broke during migration. The updated installation worked on development and internal test machines. However we were unable to procure any workstations that matched the customer configuration. We delivered the installs for the functionality test. Of course the install did not work. A developer spent at least a day speaking with a system administrator at the customer site. But there was little to no progress.<br /><br />I got the message that the development manager wanted to have a conference call to discuss the problem. We got all the facts regarding what our install developer had found. The manager wanted to see if there was anything we could do to speed up the install process. We decided that we could have the system administrator manually install and configure our application on the test workstations. The estimated time to complete this task would be about noon the next day. Fearing increased risk and schedule slippage, the manager asked how we could reel in that estimate to 7:00am the next day. This is where the conversations broke down.<br /><br />Development proposed that the install scripts could be broken up which might relieve some of the risk. However the estimate was still at 12:00 noon. And so the manager continued to ask what we could do to reel in the estimate. That’s when we heard crickets chirping. We had already factored in developers staying late and bringing the work home to complete. So the manager wanted to review what it was that we were going to do from the top. It was unanimous amongst developers that we could minimize risk and accelerate the task if we got a workstation configured like the client’s site. Apparently that was not an option. So the manager continued to ask what could be done to reel in the estimate.<br /><br />There were all kinds of problems going on with our meetings to deal with this problem. One part was that the software development manager was wasting a lot of time by keeping the whole development team in a meeting. The other problem was that we were not given the correct tools to do the job. Yes this might be normal for those of us who work for a pointy haired Dilbert style manager. But there has to be a better way to work in the software development world.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-48672641942778746032008-07-08T23:35:00.003-04:002008-12-10T18:07:20.818-05:00Technical Work<a href="http://4.bp.blogspot.com/_k7QkXMqfxAs/SHQyazT2D8I/AAAAAAAAAAM/t5G2_GHe67s/s1600-h/Project.jpg"><img id="BLOGGER_PHOTO_ID_5220853304060678082" style="FLOAT: left; MARGIN: 0px 10px 10px 0px; CURSOR: hand" alt="" src="http://4.bp.blogspot.com/_k7QkXMqfxAs/SHQyazT2D8I/AAAAAAAAAAM/t5G2_GHe67s/s320/Project.jpg" border="0" /></a>Throughout the year I have dealt with a lot of software managers and project managers. Most often than not, they have no clue as to what work needs to be done. So they are lost when it comes to producing schedules. Then a developer like me comes in and must spend a lot of time explaining everything to them. This goes on until the manager can produce a meaningful schedule. To me this is the opposite of adding value. If the entire task of creating a schedule was left to me, I would be able to get the job done faster. Instead I need to waste a lot of time bringing a clueless manager up to speed on the assorted development tasks.<br /><br />You will imagine my surprise on my current assignment. My manager told me we had a lot of change requests to review and cost. I dreaded a lot of wasted time. Initially my manager thought there would be minimal impact to the application suite that we maintain. I found this strange and dug into the technical aspects of the changes. It was nice to find out that my manager was right. There were a few exceptions that I mentioned to my manager. He asked me a couple questions on each of the tasks I thought we would need to do. The next thing I know, I get a whole level of effort document listing all tasks and anticipated hours required to complete them. The manager did this for my team and for a number of other teams as well.<br /><br />I find myself having more and more respect for this current manager. Perhaps he was a developer in a past life, and knows how to get technical work done. This enables me to focus on the matter at hand. I am currently designing the changes required for another huge change to our application. There is not a lot of wasted time in this arrangement. I get to go home on time. And I do not feel disgruntled because some lackeys are using up all my hours at work. Why does this good setup have to be the exception rather than the norm. It might be due to the fact that are few really good technical managers out there. Or maybe the time wasting schedule sessions are a necessary evil and will be a way of life as long as I am in software development.<br /><br />One thing is for sure. When I find a good manager, I really want to continue working under them. Hopefully this is a win-win situation. I get to work on the things that developers should be doing. And then we deliver good software on time that meets or exceeds customer expectations. Then the manager gets the big bonus for setting the team up for success. The only chore I have right now it to make sure this good manager does not get promoted to higher position or another project. I wonder how someone in my position can do that.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-42432640773600027572008-07-04T04:31:00.003-04:002008-07-04T04:35:44.486-04:00Manager JokesI work for a pretty conservative manager right now. He is known to call "short meetings" which last forever. And I have noticed that he is always good for a bad joke. When I say bad, I mean the joke is just no good (not funny). The funny thing is that the guy is trying at least. We all laugh because the jokes he produces are weak. That in and of itself is amusing.<br /><br />A couple weeks ago I found myself in the office working by my manager. Some girls walk by and asked him if he was good. He replied, "No. I'm bad". And do you know what? That line actually worked. Finally my boss nailed the punch line. Everybody including myself was cracking up. The irony of the statement was that my boss is not a bad dude. He seems like a goody two shoes. That's what made it so hilarious. I have confessed to him that his game is weak in the joke department, but that the "bad" comment was priceless.<br /><br />You got to give the manager proper credit for trying to lighten the mood with weak jokes. I do.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-30915627004927762552008-03-11T21:06:00.003-04:002008-03-11T21:13:12.145-04:00Putting Lessons to WorkThrough some unfortunate circumstances, I got drafted into leading a software development team again. I don't like doing management type work. But I might as well do a good job while I am there. It is easier to lead when you have seen examples of good and bad leadership to learn from.<br /><br />One thing I try to do it make sure I disseminate information to my team. It is no fun when you are a rank and file employee, but don't get important info from your boss. Some managers try to do this by holding regular meeting. I personally think meetings are evil and a big waste of time. So I just pass information along via e-mail. If we need a face to face, I keep the invite list small and do the meetings ad <span class="blsp-spelling-error" id="SPELLING_ERROR_0">hoc</span>.<br /><br />Another thing I do is try to help developers when they get lost. I don't want to step in and do the work for them. But they frequently need guidance to make sure they do not get into trouble. And I try to take over the administrative tasks so developers can do what they do best. A developer needs access to some data? I fill out the paperwork and make all the calls to make it happen. Another developer needs some the ability to do a new task in our trouble ticket system? I submit a ticket to system administration on their behalf. I like it when a manager takes care of these things for me. I just do what I would want somebody in charge of me to do.<br /><br />However not everyone is cut out for management and/or leadership. In fact, I do not think it is a good role for me. Yes I can get the job done effectively. But my self satisfaction is sacrificed. Time to see how I can get out of this role and back into development full time.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-1026210575721429862008-02-26T21:50:00.002-05:002008-02-26T21:57:16.846-05:00Return of the MacSometimes you get to escape bad management. Other times bad management comes back to haunt you. This is the case with me and Mac. I worked under him in a failed, huge project. The details of that project are not important. What is amazing is that a lot of people got fired. However Mac stayed clean. He somehow had the ability to avert blame for failure that was clearly on his watch. Nevertheless I found myself working for a better manager eventually.<br /><br />Then came the horror. My good manager moved on to greener pastures. And who comes back to take over my project? Yes. It was Mac. I knew we were back to bad times when Mac started making decisions. Decisiveness is actually a desirable quality. The problem with Mac is that he never informed the customer of his decisions. I guess that is because they were unpopular command decisions. So I had to call him out this on. The result was that a subordinate had to do the dirty work and give the customer the bad news. Little did we know that this subordinate would be the first of many to leave the project.<br /><br />There are a lot of other problems working for Mac. He tries to delegate everything, especially the <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">responsibility</span>. I somehow got dragged into a meeting with him and other leaders. Turned out to be a very depressing sight indeed. Lot of wasted time with nobody taking any real stances or accepting any responsibility. I often wonder how Mac remains in the organization. Perhaps it is because on paper he looks like a star. He has all kinds of degrees (like an MBA) and certifications (like the <span class="blsp-spelling-error" id="SPELLING_ERROR_1">PMP</span>). Perhaps it is time for me to high tail it out of here too. It appears the smart ones are jumping ship.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-1810846573611965882008-01-15T22:10:00.000-05:002008-01-15T22:17:47.373-05:00The Right StuffSo many of my posts have been about bad managers. Now I would like to focus on a good one. Peter Giles started out leading a team. Then he quickly became the manager of that team. I was not on the team that he managed. But I moonlighted helping them out. I found Peter's skills exceptional. He knew how to keep morale high when times were <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">tough</span>. More <span class="blsp-spelling-corrected" id="SPELLING_ERROR_1">importantly</span>, he knew how to protect rank and file employees from being bothered by customers. This allowed members of his team to get things done.<br /><br />I recall one specific instance where the customer asked if we could oversee an integration test for the customer. I told the customer that I thought this was acceptable. But Peter came out and stated that this work was out of scope and we would not be doing it. He was nice but firm with the customer. <span class="blsp-spelling-corrected" id="SPELLING_ERROR_2">Basically</span> he said this was not our job and we needed to focus on our contractual tasks. In the end, the customer found somebody else in their organization to do the work. That's a leader I want to work for.<br /><br />In a few months I got my wish. Peter was promoted to manager of the entire project. We have quite a large project too. When I went to Peter's cubicle (now a corner office), I recall noticing leadership books on his bookshelf. I guess these were not for show. Peter was easy to deal with because he started out as a developer and then became a team lead on another project.<br /><br />The irony of this good manager is that the customer decided to get rid of us and let another company take over the contract. I almost wanted to follow Peter on whatever project he transitioned to when he was done. Pete seemed unconcerned about the project ending. He made a couple calls to some friends of his, and got a couple jobs offers immediately. When you are good you get many options I suppose. I think I want to dissect more of Pete's outlook and track record in the months to come on this blog.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-40091902004909044442008-01-15T22:05:00.000-05:002008-01-15T22:10:08.824-05:00Working For a SubI guess working on troubled projects is the story of my life. At one such problem project I found myself reporting to <span class="blsp-spelling-error" id="SPELLING_ERROR_0">Pradeep</span> <span class="blsp-spelling-error" id="SPELLING_ERROR_1">Kumar</span>. <span class="blsp-spelling-error" id="SPELLING_ERROR_2">Pradeep</span> was unique in that he was not an employee of my company. He was a subcontractor. This posed a number of problems for me. I could not get straight answers to questions on company policy. <span class="blsp-spelling-error" id="SPELLING_ERROR_3">Pradeep</span> had to consult someone else before giving me even the most elementary of guesses.<br /><br /><span class="blsp-spelling-error" id="SPELLING_ERROR_4">Pradeep</span> had other problems like not having the right clearance level to view sensitive data from the client. So he had to use a hands-off policy of managing. <span class="blsp-spelling-error" id="SPELLING_ERROR_5">Pradeep</span> also came in when there was way too much work promised in too short a time. He told me he had success in many other projects. At first I thought they hired him to turn the project around.<br /><br />In the end, <span class="blsp-spelling-error" id="SPELLING_ERROR_6">Pradeep</span> just turned out to be the fall guy. There were already prior managers that were <span class="blsp-spelling-error" id="SPELLING_ERROR_7">coolateral</span> damage on our doomed project. <span class="blsp-spelling-error" id="SPELLING_ERROR_8">Pradeep</span> was just another one that got fired instead of reassigned. I actually liked <span class="blsp-spelling-error" id="SPELLING_ERROR_9">Pradeep</span> personally. But he was unable to excel and overcome the obstacles of a bad project. And a lot of it was due to the fact that he was not a direct employee of our company.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-21241560611064700962008-01-15T16:14:00.000-05:002008-01-15T16:21:10.907-05:00Too Little Too LateWhen working for another problem project, the project manager was "moved" off the project. The <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">replacement</span> manager did not last long either. He was promoted away from our project. During the couple months when this 2<span class="blsp-spelling-error" id="SPELLING_ERROR_1">nd</span> project manager was in charge, the company hired Keith <span class="blsp-spelling-error" id="SPELLING_ERROR_2">Littleton</span> to assist. Keith jumped around getting a number of titles. One thing that stuck out in my mind was Keith's first day. He stood up in a meeting of the entire project and asked where the documentation was. This struck me (and a lot of other people) as odd.<br /><br />Keith had a lot of catch phrases he would utter. But I do not think they meant anything tangible. After a while Keith ended up in control of the whole <span class="blsp-spelling-corrected" id="SPELLING_ERROR_3">project</span>. He hired a bunch of his buddies to staff the project. Some of these buddies were OK, others were lackeys. I will give Keith this. He worked a lot of hours on the job. But his management skills could be summed up as <span class="blsp-spelling-corrected" id="SPELLING_ERROR_4">incompetent</span>. He seemed to let the customer dictate how the project would be managed. All kinds of craziness ensued.<br /><br />On paper, you would think Keith was a <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">genius</span>. He had a lot of credentials. You know, things like degrees and certifications. But none of these appeared to help with his management <span class="blsp-spelling-corrected" id="SPELLING_ERROR_6">skill set</span>. Eventually Keith was also "promoted" away from the project. Last I heard he staffed up a small team that had nothing to do with software development. The company, I believe, is <span class="blsp-spelling-corrected" id="SPELLING_ERROR_7">benefiting</span> from this arrangement.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0tag:blogger.com,1999:blog-2456264490230133277.post-58637596738021566212008-01-15T15:47:00.000-05:002008-01-15T16:11:31.778-05:00Used Car SalesmanI joined a problem project a number of years ago. The problem started by a decision to <span class="blsp-spelling-corrected" id="SPELLING_ERROR_0">reengineer</span> and <span class="blsp-spelling-error" id="SPELLING_ERROR_1">reimplement</span> the entire project. So all changes in the old system that were slowly being phased in were accelerated to production. The result was a bunch of production software that was not ready for prime time. The maintenance team was managed by one Sally <span class="blsp-spelling-error" id="SPELLING_ERROR_2">Mayner</span>.<br /><br />The best way to describe Sally was that she resembled a used car saleswoman. And she was a good one at that. Sally could talk her way through unhappy customer meetings. However she was severely lacking in technical knowledge. And it appeared her goal was to cover herself from blame. The result was that a lot of team leaders under her were frequently put in front of the customer to explain the details of every single problem that was wrong with the system. This meant they were unable to spend a lot of time leading the teams that were supposed to resolve these problems.<br /><br />Like many doomed projects, the direct effect was that everybody had to work a lot of unpaid overtime. The customer demanded it. And Sally caved in to their demands. After a couple months the developers got tired of working every single weekend. Many good developers left. The others <span class="blsp-spelling-corrected" id="SPELLING_ERROR_3">just</span> revolted against Sally. Sally was sure to document this and inform senior management and the customer. I think you could call this <span class="blsp-spelling-error" id="SPELLING_ERROR_4">un</span>-management or non-management.<br /><br />In the end Sally left the company. While departing she said the reason was that she could not take the stress of facing the customers on the job. When I heard this I was puzzled. Sally did have to listen to some unhappy customers. But she passed the blame and the customer management tasks down to team leaders. So I am not sure what type of stress she was concerned about. I guess we may never know. But given a poor example of how not to manage irate customers, I can think about the <span class="blsp-spelling-corrected" id="SPELLING_ERROR_5">anti pattern</span> of better customer management and learn something.The Good Managerhttp://www.blogger.com/profile/04044492928737778185noreply@blogger.com0