Saturday, September 20, 2003

So I really am reading what I'm posting from this business process / project management site, I just don't have much to add to already good summaries.  Such a good combo! Comments11:38:04 PM

What is Accountability?. Hal's post about the meaning of project management got me thinking about accountability and how we use it in organizations. In the last three weeks, I've heard these definitions: "I want to know who's accountable. Who do I get to fire if they screw up?" "The testers/project manager/management team is accountable for the bugs. They let the developers put them in the product." (Yes, in one organization, the testers, PM, and managers were all held accountable for the developers' practices. Amazing.) I looked at dictionary.com, and found this meaning: "Liable to being called to account; answerable. See Synonyms at responsible. That can be explained: an accountable phenomenon. " So when I think about accountability, I think of the person with the answers and explanations, and the person who can make things happen. When I look at the above blaming statements, I wonder why the person blaming the other people is so quick to escape responsibility or explanations. Inevitably, the person pointing the finger of blame is the person who has the answers and ultimate responsibility. Here's what I think accountability is for managers and project managers: The ability to see the current state, in all its ambiguity. The ability to look for explanations of that state without blaming other people The ability to work with people to change the current state to the desired state, learning about the project and the product as the work evolves Accountability has nothing to do with blaming other people; it has everything to do with seeing the work and understanding how to move the work to the next state. [Managing Product Development] Comments11:37:10 PM

The People Factor in Software. Earlier this week, I was at the Rational User Conference. I was part of a dynamic panel, "The People Factor: Experts Weigh In On The Soft Side of Software." One question was about how technical managers or project managers have to be. Murray Cantor, one of the other panelists, summed it up this way: "They have to understand the dynamics of software development." Ellen Gottesdiener reminded us about the value of interim retrospectives. Kurt Bittner, author of Use Case Modeling was our moderator. I was my normal feisty self :-) I wrote up my position statement, and after editing it several times (and changing it the night before the panel), I've decided it's worth posting, at least for comments. If you were at the conference, you'll recognize that I ad-libbed during my opening remarks. Please do comment by email or with the comments here. The People Factor in Software The two most important factors for successful software projects are the ability of the managers to manage and the people to understand the domain of the software in which they are working. [1] Capers Jones claims that reuse of high quality components is significantly higher than those two factors, but to be honest, I haven't seen enough reuse to apply that factor to most projects. What that means is that people matter. And managers matter. So what do I mean by people matter? I'm not a people person by nature. I originally decided on a career in software because I thought I'd be able to interact with machines all day and rarely talk to other people. After all, that's how I went through school, and didn't school prepare me for life? Well, unsurprisingly to us now, I soon realized I spent close to half my time talking with other people: discussing the designs, how we would integrate, who would get computer time, which module would do what thing, and who would manage the work in software that the hardware guys couldn't do. As I became more aware that people are the vehicle by which software is developed, I realized I had to "care" about people. I don't mean caring about people in a touchy-feely way Â? although I do recognize that people have feelings. I care about people and they way they interact because that's how we make successful products and projects: It's logical to care about people because if the product is a success but the people all quit at the end of the project, the project was not successful. It's logical to care about people because if they're worried about the rest of their lives, they can't give 100% to the project. It's logical to care about people because if they work so much overtime that they're punchy, they will create defects (if they're developers) or miss defects (if they're testers) or set the organization on the wrong strategy (management) People are how we make projects successful. But what about managers? Earlier, I said that managers matter too. Here's why. Good people can triumph over inadequate process or inadequate management. But even the best people with the best process can't triumph over bad management. Bad management trumps everything else. I've worked for bad managers, and I bet you have too, so you've seen the damage bad managers can cause. Great managers recognize that any software worth doing has to provide significant value over previous (or other) projects. Managers, as well as the technical staff know they have to learn about the software as it evolves so they can manage the unknown risks. As I was driving in yesterday on US 4, I saw lots of construction. I realized that the people rebuilding the road were working on the next release of the highway, something we do in software as a matter of course. But there's huge difference between managing people who construct the next rev of the highway and managing the next software release. With the first release of the road, you've already uncovered most of the construction gotcha's. You know where the water table is, you know where the animal habitats are, you know the ground composition as you move along the highway. In software Â? any software worth doing Â? you don't know what you're going to find. Just because you discovered something in the first release, doesn't mean you know enough about how the software has to evolve to understand what's going to happen in the next release, with the new requirements and the changed implementation. You have tons of unknown risks. I claim that the best managers help their staff recognize and manage those unknown risks. The worst managers don't. And because unknown risks can occur anywhere, the best managers use qualitative and quantitative data to understand the state of their projects. Successful organizations work on the highest value projects; hire people who can succeed in their environment; and teach those people, including the managers about the product. Managers who understand that their job is not just to deliver results for this particular project, but also to continually build capacity and work through and with others are successful. Technical people who are continuously curious about the product and how to make it better drive projects to successful completion. We need people who are knowledgeable in two significant dimensions: they understand what their job entails (whether they are developers, testers, release engineers, and so on), and they know how to apply that knowledge to the product. We need knowledgeable managers, people who understand how to manage projects and people, and who know enough about the product to make good decisions. I claim that the practice of software management in 2003 remains significantly behind any of the technical factors in producing great software. When we decide management is valuable and we demand managers perform good management, we will build capacity in each person and our products will improve. The soft side of software, the people, are the trump card in software projects. Want a successful project? Make sure your people can work together, including their managers, and that they understand the problem and solution domains of the software. Make sure your people have the functional skills to succeed. Then you can select any reasonable process, and the people will succeed. 1. Jones, Capers. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley, Upper Saddle River, NJ. 2000. (page 133). [Managing Product Development] Comments11:36:33 PM

What if Managers Worked Smarter?. I was reading David Anderson's Working Smarter Not Harder and thought about managers. David's right, a few small improvements can dramatically increase a team's productivity and therefore lower the cost of development. But I contend that most of the productivity costs in software is the way we mismanage software projects. If managers worked smarter, they would: Assign people to only one #1 priority task at a time Assign people to only one project at a time Create opportunities for people to work together, to build review into the product development process Ask about obstacles Clear those obstacles I'm convinced that the reasons outsourcing works is that it forces organizations to document requirements and the outsourcers work on only one project at a time. The outsourcers' management can then choose any number of useful product development practices that increase the outsourcers' productivity. Management can't change their minds and refocus the outsourced project(s) in the same way they feel free to refocus the internal projects. [Managing Product Development] Comments11:35:43 PM

Enabling Serendipity. Hal asks a fascinating question in Variation is an Enemy Enabler of Project Success: How can we take advantage of serendipity rather than forcing an outcome in our projects? (paraphrased) One technique is to observe and listen to the project. When PMs observe their projects, they look at and listen to: How people work together. Are they talking? Peer reviewing? Pair-working? Any other technique for informal communication and information sharing? We can take more advantage of serendipity when people collect the bits of information about other areas of the project. How project meetings flow. Do people want to attend? If not, what would make the meeting more useful? If people feel free to discuss their obstacles, other people might have techniques for overcoming those obstacles. Daily progress. Are people making some form of progress every day? Even if the progress is learning about the project, not deliverables, the project team needs to make progress every day. Effects of multi-tasking or long hours. Multi-tasking extends the project duration (if you don't believe me, look at Frank Patrick's blog), and long hours makes people stupid. There's more, but it's eluding me now. I'll add more when I can remember. I take advantage of the serendipity with one-on-ones, project team meetings, MBWAL (management by walking around and listening), lunch with the project team (or others), anything that gets me out of my office to observe and listen to the project. [Managing Product Development] Comments11:34:56 PM

"The Business Value of Web Standards" Comments11:06:24 AM

Anna Sewell. "I am never afraid of what I know." EXACTLY!  Though sometimes I know things and reject them as truth. Comments2:16:46 AM

Best Practices for Software Development Projects. 10 simple tips to get projects in on time and within budget. [Computerworld News] Comments2:16:08 AM

When I moved to Maryland almost 3 years ago I moved with what would fit in my car.  I sometimes have the urge to pick up and go back with that.  There's a safety to home.  A feeling of absolute love regardless of whether you step on someone's toes or say the right things. Of not having to prove yourself over and over and over again non-stop.  It's not that I didn't experience these emotions in Arkansas, just not at home.  Can a home of one ever really supply that same comfort? I hate the rejection friendship and relationships often bring.  So hard to match up equal feelings.  I'm not sure I have one single equal relationship here.  Not one single one.  I often feel like the people I love the most could go the rest of their lives without talking to me and it would be okay.  That's not fair!  And I don't think it's true for my family or a very small number (3) of friends.  Maybe I should feel lucky that I even have that many, but I can't make myself stop loving my other friends.  So hard to not question what's wrong with me that they don't love me as much.  And I have this stupid fear of failure that makes it impossible for me to start some things.   I should be more in my career. I'm about to be 26 and I'm not any further along than a year ago.  I used to jump for opportunities and ask for them.  Not I shy away 'cause I'm pushing my comfort zone and I'm afraid I won't be good.  That if I stick my neck out my head will be cut off.  So those are my fears and self-doubts tonight. Comments2:10:05 AM

© Copyright 2005 Rebecca Schwoch. Last update: 2/8/2005; 2:13:52 PM.