Managing Product Development

One of the big problems in organizations (IT or product-shipping) is how to fund projects. I don’t believe in ROI (Return on Investment). I learned how to lie with ROI back in 1988–I can make the numbers be anything you want. If you don’t have ROI, how do you know what projects to fund?

One set of projects is the set that if you don’t do, you can’t compete. Have a hardware-software solution? Better be thinking darn hard about a software-only solution that runs on several platforms. Or, a Big Gorilla  vendor such as Microsoft or Oracle changes what they support. You have to upgrade to a new platform.

But all the other projects, especially the risky projects, how do you fund those? Incrementally.

I don’t give my kids their allowance yearly. They get their allowance once a week. They get a clothing allowance in two parts, so that they can’t spend all their money on fall clothes and have nothing for the summer. That’s the same idea as funding software projects incrementally.

Of course, that means you have to build software projects incrementally, in some sort of a timebox. (Gotcha!) But here’s why it make sense to do that:

• If you show value to someone, preferably your customer, you are much more likely to get more funding.
• If you’re not showing value early and often, you get feedback early enough to change before you start a death march for something your customers don’t want.
• You can start highly risky projects, because you’re not committing a ton of money and time to that much risk. You’re just committing 2, 3, or 4 weeks.

If you’re having trouble getting your projects funded, stop asking for the whole huge project. Make the project show value first, fund that value first, and see how much it actually cost you to provide that value. Now you have a little information and can decide whether or not to continue. You never have to throw good money after bad.

I was speaking with a potential client about their approach to knowledge management. They think they need a senior person to organize a top-down appoach, and build a custom tool, so they know what knowledge they want to manage and have a place to put it.

I don’t think that’s going to work. That approach requires they know what kinds of knowledge they need to store and who will need access to it, and when. They don’t know any of that now.

Here’s what I know about knowledge management:

• You can’t create an electronic system until you understand what you’re trying to manage. That’s because the kind of information changes over time, not just the content.
• The Dreyfus model of knowledge acquisition infers that electronic systems are fine for novices, advanced beginners, and maybe the competents. But the people who really make a difference in the organization are the proficient and expert folks. Those people cannot easily put their knowledge into an electronic system, nor can the other people acquire their knowledge that way. Knowledge has to be transferred one-on-one, within a team, inside groups, between groups, and company-wide as the very last step.
• If you put people in competition with each other *in any way*, they will have dis-incentives to share their knowledge.

Given all of that, it’s not clear to me a top-down approach to knowledge management can work at all. What I do see as necessary is to have the managers (or some person):

• See the pockets of knowledge
• Plan some adaptive, people-based, timeboxed systems of knowledge management
• Measure where the knowledge management systems are headed
• And steer the people to do better

To me, agile approaches would work well. You could try something for a short timebox and see if it’s working. If so, keep doing it until it doesn’t work or needs another storage mechanism. Now you’ve got some experience to know what you need.

Starting with a tool is backwards, if you really want the experts who have substantial intuition to impart their knowledge.

I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why.

If you commit to implementing features (not chunks of architecture)  based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in a timeboxed iteration, and the testing is incorporated into the iteration, there’s no (ok, very little) time lag between the time you know what a requirement is supposed to be, and the time the requirement is implemented and tested. Now it’s a simple matter of paperwork (ok, maybe not trivial) to match the requirement with the code and the test. If you do test-driven development, and start with user-facing tests, it’s even easier.

The shorter your timebox, the easier traceability is. That’s because you have fewer features and fewer tests to manage.

Some of my clients keep their index cards and organize the traceability that way, with notes about where the tests are. They lock the index cards (post-iteration) in a fireproof safe. Other folks use a spreadsheet for the organizing. They use a source control system to manage the changes to the file.

Remember, the requirement is to trace the requirements through the code and tests and to be able to show you did that. The fewer artifacts, the better.

I have a Stickyminds column up, Does Exploratory Testing Have A Place On Agile Teams? The column arose out of an email conversation I had with Jon Bach. Please leave comments there.

I’ve been working with several clients on their transitions to agile–or at least, more agile approaches to their projects. In each case, the managers decided to move towards agile because the technical staff were in their words, “naive” about the project goals. To be fair, none of the projects had a vision or release criteria, so it’s not surprising the technical folks didn’t understand the project goals.

But waterfall, with it’s emphases on understanding up front,  helps create that naivete. If you could understand requirements or design up front, then the project is just a SMOP (Simple Matter of Programming). And the testing is just a SMOT, and the writing is just a SMO (Testing and Writing). With a SMOP attitude, everyone assumes the predictive schedules are correct, creating a sense of naivete for the entire project–not just the technical staff. The managers are naive about what the milestones really mean, and everyone’s naive about the entire schedule.

But there’s an even more insidious  assumption in waterfall: that the time to finish the project doesn’t matter. This attitude arises even more if a senior manager or program manager or project manager says something like, “Quality is Job 1.” At some point, this project has to end and the product has to ship. Maybe not next month, maybe not even next year, maybe the year after. But at some point in time, the product will ship, regardless of the technical staff’s perception of quality. And that’s where waterfall lets down the entire project team.

I haven’t worked on a project or consulted with a company where they had endless time to get to release for at least 20 years. (I can only remember one project where we were not under time pressure back in the early 80’s. But maybe I can’t remember much Granted, I tend to work on or with projects in commercial organizations, so if you’re working on a government project, maybe you have more flexibility in time.

But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)

Waterfall is fine for a few weeks (4 or fewer), and a few people (4 or fewer) and where you’re sure the requirements are not going to change. Absolutely, positively sure. No surprises. But if you have a larger project or a longer project or you have a suspicion things might change, you want to work differently. I recommend you read my recent Cutter IT article, What Lifecycle? Selecting the Right Model for Your Project to see ways to organize your projects so they make more sense.

Naivete can be charming in people. But it makes for badly organized and executed projects and programs. Waterfall reinforces naivete. Any other lifecycle allows you to take a more empirical approach, rather than a more predictive approach. The agile lifecycles are all about empiricism, so they banish naivete–at least, about schedule–completely. Choose any other lifecycle, and you can take a mature, not a naive, approach to your projects.

One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release.

For an agile team, do you know what done means for your timebox? Is all the code tested? By whom? Is it all checked in? Does it build without problems? Can you demo the product? Can you release the product? I much prefer product that is developed, fully tested by developers, system tested by the testers, and could be released–what I call release-able. But that might not fit for your project. If the product is only demo-able, make sure everyone knows that you still have technical debt and will need another timebox for testing and fixing.

For every team, develop release criteria. That way you’ll know what done means for the project as a whole.

For a team using any lifecycle other than agile, make sure you have interim milestones and criteria for those milestones, so the team has early feedback about the project’s progress. And, measure your progress towards your release criteria.

Deb Hartmann interviewed me (video and audio!) at Agile 2007. We mostly talked about schedule games from Manage It. (We briefly discussed Behind Closed Doors: Secrets of Great Management and Hiring the Best Knowedge Workers, Techies & Nerds.)

For those of you who’ve met me and are wondering, “Where are Johanna’s glasses?” They’re in my lap. They were reflecting too much, so I took them off. Luckily I could see well enough to have a conversation with Deb.

David Daly interviewed me, PM Interviews: Johanna Rothman by email. I answered in American spelling and he translated into UK/English spelling

PM Boulevard just published How Often Should You Review the Project Portfolio?. You have to be a member to see whole article (membership is free). You can’t leave comments there, so please leave them here.

Clarke Ching interviewed me by email. Here’s the link to the first question: Q1. There are a total of 7 questions.