Managing Product Development

Dwayne’s comment on my post, Architecting from the Features, made me realize I hadn’t provided an example of how I’d changed the book. Head slap on me! One of my rules of writing, which I use when I’m revising because I rarely remember as I’m writing the first draft, is to explain what I’m writing with an example. Examples can be a “for instance”, a story, an anecdotes–anything that connects my writing to the reader. Some people like stories first. Some like the idea first. But both of those kinds of readers will stay with your writing if they know you’ll get to the other part sometime soon.

So here’s the before an after table of contents for the project portfolio management book. I fully expect the chapter titles and contents to change.

I’ve got the notions of the reader’s span of control in “Making Great Portfolio Decisions” rather than in separate chapters, which is making it easier for me to write that and the other chapters.

Dwayne, thanks for asking for an example.

I’m writing the portfolio management book, and I just finished a whole big re-architecture. I’m so excited.

I realize most people aren’t that excited about a rearchitecture :-), especially not of a book in progress. But I am, because I took my own advice.

When I started writing the book, I had several partly done chapter-things. They were not particularly well-written, nor were they coherent and several pieces were tightly coupled. But they were enough for the Prags to see what I was thinking. Luckily, that was enough for a contract.

I’ve been writing off and on since I got the contract, and have been getting stuck. I realized last week it was time to print the book and start cutting pieces of it to reorganize.

I finally started making the book (yes, I write in markup language, check my writing into Subversion, and use make to make the book), and seeing it on paper helped me see where my features were.

I have some user stories:

• “As a first level manager or technical lead, I want to see how to make a portfolio.”
• “As a middle manager, I want to see how to make a portfolio and make decisions about it.”
• “As a senior manager, I want to review the portfolio, and make decisions about it based on data.”

But being your own product owner is not such a good idea. Because I thought the roles were driving the book, I had separated a bunch of the writing by role first, and then what the roles did. But it turns out, that for this book, right now, the portfolio activities are what needs to drive the book. Maybe that’s obvious to you. But it wasn’t for me.

I realize the current book’s architecture may not last. But I can see how to write more of it. And, I’ve been refactoring to clean up my writing. I think of the refactoring as where I put things to make the book clearer, and editing as how I change the words to make the ideas clearer.

I wrote several features–actually parts of several features because I got stuck. Now I’ve rearchitected and the writing is flowing. I’m probably not done rearchitecting, but that’s ok. I have a place to head towards now. Onward!

I was under the weather last week, and am finally well enough to think. I still have the raspy voice from coughing all week, but you can’t hear me. Since I worked out this morning, my brain is actually firing on all cylinders.

I signed a contract with Pragmatic Bookshelf for my next book about project portfolio management. This time, they wanted a schedule. I know I write in fits and spurts, so I was stumped. But I decided to take my own advice. I have a plan to timebox the writing in chunks, and I gave myself quarterly goals of a certain number of pages. Writing that number of pages isn’t a problem–writing that number of good pages might be a problem. I’ll be trying things out on you, I’m sure.

If you’re not sure the world needs a book on project portfolio management, take a look at Raven’s Project Management Cartoon from Project: Humor - Water Me. Sad, but too true.

During the past few week, while editing Successful Project Management, I had an opportunity learned to discover other ways I weaken my writing.

I already knew about “get” and “put” and “do”–any words you can command a computer–are weak verbs. It’s ok to use them to start writing, but my writing is stronger when I change those verbs to describe what I really want. I’d changed “Get people” to “Acquire people.” Luckily, Esther reminded me we don’t acquire people in organizations; we recruit, attract, or hire them, but we don’t acquire them. (That’s why we have review

I also knew about the “lullaby” words: “just” is my favorite.

But I hadn’t realized I was so enamored of “in order to,” “So,” or “Now.” I managed to find all the “in order to” and remove the “in order”. That helped me see what I really wanted to say. “Find a large wall in order to post your project dashboard” became “Find a large wall to post your project dashboard” which became “Post your project dashboard on a large wall.” (That’s an example, not a quote.) I started too many sentences with “So;” so I removed them all. (I might have 2 left, in dialogue.) Now, With those edits complete, I could attack the “now” removals. I used “now” as a way to sequence actions, without making a list.

I’m sure I have more strengthening to do can strengthen my writing more. The copyeditor is great, so I’ll have lots of ideas/fixes when the copyediting is complete.

Labels: Manage It, Successful Project Management, writing

I’m in what I hope is final editing for Successful Project Management. (I”m still doing gross editing, final copyediting is one more stage. But I’m not supposed to change ideas in that stage

If you want to know how to write a book, read PragDave’s series of So You Want to Write a Book. I’m rewriting several chapters that I didn’t get right early in the writing. I had not yet found my voice. I think I now have. Here’s a link to what Dave says about Finding Your Voice.

Roy says Writing A book Is Like Developing Software. I completely agree.

So my challenges now are to keep to topic and not add more. (It’s already long enough.) I actually have release criteria for the book. (Bet you’re not surprised

Once I receive more feedback from my editor, to see if the changes I’ve made are good, I’ll be able to get into the small markup editing. I won’t be making April 2 as a release date. Sorry.

Labels: Manage It, Successful Project Management, writing

True confessions: I was hoping to finish the draft (of Successful Project Management) for technical review today. I didn’t. I knew on Tuesday and called Daniel to let him know where I was.

This past week I focused on finishing chapters. I have about 16 chapters and one appendix. I don’t know if the book will keep its current architecture; I removed one chapter yesterday. I have three chapters to finish (somewhere between 10,000-15,000 words) and three to rewrite (changing about 15,000 words? and a bunch of pictures). When I’m cranking, I can write close to 5000 words a day. Oh, and in case you’re wondering, I’m writing in markup language, so I don’t know how many of those words are markup and how many are content words. (This is similar to the problem of comments vs code when you count lines of code

I’ve noticed these patterns in my writing over the last couple of months:

• When I know something cold, I use a form of mental shorthand. I write using that shorthand, losing my readers. I need reviewers to let me know I’ve lost them.
• When Daniel reviews my writing, he helps me refactor (yes, simplify) and I typically lose 10% of the words.
• I’m getting better at seeing when a piece is mis-organized, but I’m still not so hot at organizing it until I get feedback from someone.

So my next deadline is Jan 1, to finish this draft and have the book ready for tech review. It will be tight, but do-able.

I’m writing part of the PM book, and said this about the minimum requirements for a configuration management system (CMS):

Modern CMSs can branch, label, automatically merge multiple authors’ changes, and allow for developers to work in their own private workspaces (sandboxes). If your CMS can’t do that, dump it and obtain a new one.

The reason I’m saying this is because I still see people using CMSs that don’t allow for sandboxes, don’t branch easily, and don’t perform automatic merging well. It slows development (and the project) down dramatically. Did I miss anything?

Update as of Dec 1: I changed the acronym in the book to SCM. Did a global find and replace and it’s done. Phew!

I’m busy writing the PM book, and saw these great posts. So instead of making myself crazy trying to write more good stuff for you, I decided you should read these.

What is managing software development? is a great read. BTW, the working definition I have of project manager is: the person who knows what “done” means and can steer the project to accomplish “done.”

Difference Between Planing and Scheduling talks about the difference. For me, project management planning is the identification of release criteria and other prose about the project. Scheduling is the WBS, whether that’s on yellow stickies or not.

Esther, in her Get out of your way! post describes a situation where by our behaviors, we cause the thing we don’t want to happen. It happened to me this week.

I’ve been working on the PM book, and I’ve been struggling with the lifecycle chapter for a couple of months now. Probably longer, since I knew I was struggling in mid-October, and I’d already been messing with it for longer than that. I drew more pictures, wrote more text, and it still wasn’t working. I finally asked for feedback from Esther and Andy.

I’m so glad I did. They were able to articulate what’s not working with this chapter. I’ll be rewriting it, as soon as I have a few things worked out in my head (I have a few other things to finish first).

But that’s my pattern–to wait too long for review. First I struggle with the writing, adding more words and pictures. Even when I edit, I add more. How’s that working for me? Not well

The thing I don’t want to happen is to be late with the first draft of the book. But by not asking for help earlier, I might cause that to happen. (We’ll see. I’m in danger of being late, and I’m in danger of making my deadline. I can’t actually tell where I am in the schedule, and won’t know for another couple of days.)

If you’re in a position where things aren’t quite working, Esther’s question, “How’s that working for you?” might jolt you out of your self-reassurances that things are just fine. It worked for me.

Keith Ray, Dale Emery, and I are writing books. Keith and Dale are tracking their writing with spreadsheets. Dale is posting his progress online. You can see his Oct 8 progress.I decided they were on to something, and start tracking my progress in a spreadsheet also. I have about 35,000 words written. I have about 1/3 of the chapters in progress. Maybe. It depends on when I realize I have to write more or less about a topic.For Hiring the Best Knowledge Workers, Techies & Nerds, I wrote each chapter, sent it to my reviewers, got feedback, wrote the next one, and so on. For Behind Closed Doors: Secrets of Great Management, Esther and I first wrote the first draft, got review comments, wrote the second draft, got review comments, pair-wrote the third draft and got review comments.For this book, I’m working with an editor now, so I’m hearing about weaknesses in the writing as soon as I tell him something is available for editing. This is way cool. In a sense, I’m refactoring as I write. (Oh yes, there’s a lot of simplification and clarification going on :-)I’m noticing that when I write down the first draft, I still have a big burst of words, but as soon as Daniel starts giving me feedback, the word count doesn’t change all that much, but does tend to decrease.I’m enjoying the writing-down part of this book more than I expected, because I am receiving more feedback faster. This is the same thing that happens on projects when you have cross-functional teams working on one feature at time. I’m pleased to see how well it works for writing a natural language too.