"But It's Just a Small Change"

I had the pleasure of speaking with two different colleagues today, both with the same dilemma. They are near the end of their projects. They don't quite have enough time for one round of final testing--but if they're lucky and the stars align, and they don't find too many problems, they can still (maybe) test what they need to test before the desired release date.

But no, the stars don't align. First week into testing, they find a nuisance of a defect. It only occurs once--in installation, and they can work around this with release notes--but they're under pressure to make the change. They each asked me what I would do.

After asking a few questions to make sure the problem only occurs when installing, and they can make big red stickers to explain to the customers what to do, I agreed with the PMs: don't make the change.

The risk is just too high. The reason the projects don't quite have enough time for testing is that they've encountered trouble all the way through the projects. The builds take too long. The developers didn't integrate testing as they developed. They implemented by architecture, and couldn't manage the changes in requirements, so the architecture doesn't quite fit what the customers want--but they shoehorned the features in anyway. The project team hasn't met one deadline yet.

If you're in this position with your project team, ask yourself and the team this question: What did you see or hear that leads you to believe this would work?

If the someone has data, "Oh, we fixed the build and we can tell in 10 minutes if the build is any good," maybe you can agree with the decision to make the change.

But if all you hear is gut feelings, say no. Murphy is one of your team members. Finish this project. Hold a retrospective. Work differently on the next one. But don't make that one small change. It won't be small. It probably won't work, and you won't know until the customers receive the product. The risk is too great.

Pragmatic Manager Pages Updated

I just finished updating all my email newsletter (Pragmatic Manager) pages. I hadn't announced my most recent newsletter, Making Waterfall (a Serial Lifecycle) Work For You, Part 1 (Vol 4, #1). I've reorganized the pages, so go here to read all the previous articles.

Project Managers are Not Business Analysts

Kevin says in his comment:

Business analysis is how you figure out what done means. Project management is how you figure out how to get to done.

I disagree. Business analysis is the elicitation and definition of what everyone else wants to have in the product. Project management is understanding what's driving the project, and leading the team to fit as many of those "what everyone wants in the project", with the desired quality in the time frame. Business analysts don't get to define "done." They don't have enough context. (Yes, there are some business analysts who can do this, especially if their PMs don't. I bet Kevin is one of these multi-talented folks.) The PM and the project team define "done" and how they will get there, not the BAs.

Too Simple a Definition of a Project

Via Raven's Think you know what a project is?, there's a pointer to What is a Project? Think Again!. Garry, the author likes David Allen's definition of a project:

A project is any outcome you’re committed to achieving that will take more than one action step to complete.

I don't disagree with that on a personal level. But I don't think that's enough for a project manager inside an organization. I prefer Max Wideman's version:

A novel undertaking or systematic process to create a new product or service, the delivery of which signals completion. Projects involve risk and are typically constrained by limited resources.

That leads me to my definition of a project manager:

The person whose job it is to articulate and communicate what done means and to guide the project team to done. By done, I mean a product that meets the needs of the organization developing the product and the customers who will use the product.

Gantt Charts and Agile

I don't have much use for Gantt charts; if you've determined the tasks in enough detail and far enough out to really see the critical path, you'll be wrong in 24-48 hours. If you don't put in that much detail, it's a pretty picture, but not enough information to manage the project. (Of course, Gantt charts are used by people other than the project manager and the project team--but mostly for nefarious purposes :-)

Tate Stuntz in The demise of the Gantt Chart in Agile Software Projects has a great article about why Gantts are not useful in Agile projects.

Aside: I'm happy to report there are no Gantt charts in Manage It! Your Guide to Modern, Pragmatic Project Management. That's because there are other charts that provide much more detail, with more accuracy.

When Is Defect Data Not About Defects?

I taught my Pragmatic Project Management workshop in Israel last week. I was talking about defect charts and what they mean and how I use them. (No, I don't include priority or severity data on defect charts; just # opened and closed by week and # remaining open each week.

One of the participants explained that he also tracks # Fixed Private Defects. What are those? Fixed defects in a developer's sandbox, not checked into the mainline. Why are they not checked into the mainline? Because the organization does staged integration of several highly complex sub-projects, each of which has interdependencies with the other. And the build takes over a day.

This participant's defect data is not about defects. This data is about the cost of the build and possibly the product's architecture. When you can't build the whole product every day (this organization builds a couple of times a week), you create a bottleneck of fixes waiting to be integrated into the build. You slow down development--dramatically at the end of a project, badly enough during the project--to keep the build going.

Let's run a few numbers and see what it costs them to continue staged integration. Let's assume it costs just one person-day to create a fix. (That's optimistic, but not unrealistic.) Now, assume that for three months of a project, they have a weekly average of 50 "private-fixes" waiting to be integrated. (I'm assuming the 50 here, I have no data. But I think it's not far off reality.)

To keep staged integration going, they spend 50 person-days every week for 12 weeks. (Remember, this is a large project, really a program.) That's 600 person-days. I wonder if they could spend 600 person-days and fix the build so that they could build every day, without the need for staged integration. I don't know, but I suspect they could.

Watch for what your data is telling you. You might think you're measuring one thing, but you're really measuring something else. In this case, the defect data is not about defects; it's about the cost of an inadequate build system. What else are your defects telling you about your system?

Portfolio Management is Not Project Management

While teaching a management class recently, one participant came up to me at a break, and said, "Why are you teaching us project management with this portfolio stuff? This is supposed to be a management workshop."

Portfolio management, determining which projects to fund and when, is management work. The best managers actively manage the portfolio, saying yes, no, and when to projects.

When project managers try to do portfolio management, many of them feel torn when they try to balance when to start each project. They can see the reasons for each project, and may not have enough information to be able to actually determine the strategy behind what the portfolio should be.

If you're a project manager, it's possible you have to define the portfolio of projects, just to keep your sanity. (That's why there's a chapter about portfolio management in Manage It!) But it's not project management. Your managers need to make those strategic decisions about what to do and when.

Manage it! is Available

Drum roll please...

Manage It! Your Guide to Modern Pragmatic Project Management is available. (I don't know when it will be available from Amazon. Soon, I suspect.)

See the press release. I'm sooo excited.

Two Good Rules

In his recent IEEE Software column, "Ship Effortlessly" J.B. Rainsberger has a gem:

I start each project with two rules: all source files must be in a version control repository, and the build must be fully automated at all times.

Does your project follow these rules? If not, what would you have to do?

It's worth the time to invest to make sure you know which sources are which. And if you automate the build and it still takes "too long," you can measure what's too long and you can determine which actions to take.

Services to the Organization

There are several questioning comments on my post Testing is Not a Service: What do I mean by testing and how do I reconcile my statement with the context-driven school of testing?

Let me clarify what I mean by service first. The way the participants were discussing testing as a service, they meant a common service to the organization, not the project. In the same way that accounting is a service to the organization, or the HR is a service to the organization, their organizations thought that testing was something that could be applied to projects (frequently long after development "finished"), in the same way that other organizational services could be applied to the organization.

But if you think of testing as a service, it's applied to a project, not an organization. In a waterfall lifecycle, where the bulk of testing occurs at the end, it's barely possible to have effective testing after development. It costs more in time, risk, and money. The testers take much more time to find problems because they're not integrated into the project. It's likely the testers will not find the problems the customers will. The cost to fix a defect is much higher. But the kinds of testing these people were talking about, "Spend a couple of weeks testing this app," or my favorite, "Go over it lightly" is not effective for the product or the people. Those aren't services to the project; they are a service to the organization--an ineffective service to the organization.

To me, testing is a part of development. When I talk about development, I mean code and test and documentation development, because I mean product development. Whatever it takes for the whole product is part of development. In that sense, testing is a service to the project, but definitely not a service to the organization. Product development is the service to the organization. Cost effective, reduced-risk product development requires integrated testing.

So how do I reconcile my view of testing (a component of product development) with the context-driven school of testing? Look at the The Seven Basic Principles of the Context-Driven School. My statements are congruent. Especially see: Testing groups exist to provide testing-related services. They do not run the development project; they serve the project. (They don't serve the organization; they serve the project.

Product development is the goal, not code development or test development. Effective product development requires an integrated team, who all provide services to the project, not the organization.

Testing is Not a Service

I taught a one-day workshop at StarEast yesterday with Esther. I was astonished at the number of test managers who think testing is a service.

Effective testing is not a service. Effective testing is an integral part of development. When people--especially senior management--consider testing a service, there are inevitable consequences:

• Testers multitask between several projects, learning none of them in detail and only cursorily testing any of them. It's hard to see the value in that kind of testing.
• Few managers make the decision about what project is most important, so ordering projects by value or risk doesn't happen until the project is in test.
• Testers don't work with developers, so defect reports look more like blaming the developers rather than feedback to the developers.
• Because testing is a service, project managers and developers tend to throw the product over the wall to test. Instead of collaboration, the project is in an us vs. them dynamic. Too few developers make the extra effort to find all their issues before the testers do. Why should they? There's nothing in it for them.

This perception of testing as a service is a misunderstanding of the dynamics of software development.

When you contrast testing as a part of the development team, developers are much more likely to form partnerships with testers, to clean up their code as much as possible, and to exhibit professional pride in their work. They take defect reports as feedback.

If you're a project manager don't treat testing as a service. Make it an integral part of development.

Manage It! Book Status

I am happy to report that Manage It! is at the printer, both the book and the cover. We're looking sometime in June as a ship date. Just thought you'd want to know :-)

Milestones are Handoffs

I taught a workshop about transitioning to Agile earlier this week. One of the things that's difficult for many project managers to recognize is that milestones must be deliverables--otherwise, it's too hard to know when something is done.

One of the participants had a slightly puzzled look on his face when I said that, so I'm not now thinking that another way to think about milestones is to call them handoffs. If everyone has the idea that their milestone is really a handoff to someone else in the project, you're more likely to get to "done" for a milestone.

Updated later Friday, changed a "not" to a "now." Thanks Jason, for letting me know I made not enough sense :-)

Stickyminds Column About Project Vision

I have a new column up on Stickyminds.com, What's Your Project Vision? Please do visit and leave comments.

Multitasking is Conflict Avoidance

There's a great quote over at The pernicious thinking behind multi-tasking.

Note the admission that required multi-tasking is an implicit means to avoid conflicts around setting priorities.

I've been doing a bunch of multitasking talks this year (and suggesting ways for people to say no), and have written about it in Successful Project Management. (I did rename the section that originally said, "Multitasking is the root of all evil.") When I talk about it, and tell people it makes no sense, at least part of the time they say "Ooh." Too many people have no idea what the cost of multitasking is.

But the conflict avoidance part is because management, especially senior management is unwilling to make the hard decisions about what's most important to do. That's unacceptable. Managers are the only people who can make these most strategic decisions.

Multitasking guarantees your project will be late. If managers don't make the decisions, project staff will. And it won't be the way the managers want it.

Can You See Your Project's Dashboard?

In the PM (it's actually called "software methodology, but I assign a project, so students can experiment with methodologies) class I teach at TGI, I ask the students to create (and then use) a project dashboard, so they have a quantitative way to see their progress (or lack thereof). The students presented their dashboards last week.

One of the teams adapted a traffic light, with red, yellow, green, and blue (for done). The student who presented the traffic light to the class, said something like this, "We added blue, to denote done. I think it's right there." I said, "Can't you see it?" He said, "No, I'm color blind."

I did about 5 minutes of online "research" and realized that about 5-7% of men can't distinguish red from green. Some fewer can't distinguish between blue and green (the problem my student had).

So, if you're going to use a traffic light (which I don't like. See Sunny Skies or Storms? for an alternative to the traffic light), make sure your viewers can see it.

Scheduling the Project is a Team Activity

Glen Alleman in What's Wrong With This Picture says this:

dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business capabilities and their associated value to the customer - did I mention the Customer is accountable for the credibility of these activities as well.

I agree. That means that the team has to define and organize the schedule. And that the Customer has to understand it and be accountable for it. That's why schedule games are so difficult for the team to deal with.

Automated Testing Helps Scrum Succeed

Guy in his We love Scrum at GigaSpaces, says something critical:

[...]we've been working in the past couple of months on upgrading our automated testing framework. I've been assigning five of my top engineers and architects on a project with the objective to provide the development team fast feedback and monitors on quality. Now we are able to identify specific source commits that either affect the product performance and stability. We identify those and fix them immediately. The turn-around is less than 48 hours of the cycle[...]

Scrum is the project management framework. And, Guy realized that having early feedback to developers in the form of an automated unit testing framework was critical for the success of the project management framework.

Notice that Guy assigned five of his top engieners and architects to the automated test framework. Testing in-process is hard work. If you don't have the ability to develop and maintain an automated test framework for your project, put your best people on it, as Guy did. You won't regret it.

Creating a Partnership Between the PM and the Architect

Udi has a great post, Money?! Schedule?! But I’m an architect, not a PM!. In it, he discusses a question he posed to other architects:

“When can you have your solution in production and how much would it cost?”

Ideally, the architect would discuss this with the technical staff and the project manager. More ideally, the architecture would emerge from prototypes. Even more ideally, from tested and implemented features.

But no matter how you and your team define an architecture, at some point everyone needs to know how long it will take and how much it will cost. To have an accurate idea, the PM and the architect need to partner on what "done" means, to estimate with the team all the pieces that go into this architecture, and to know how to assess progress, so everyone can tell how long and how much.

If your architect isn't partnering with you, think about what you need to do to partner with the architect. It's worth it. Otherwise, you really don't know when it's done and how much it costs--until the bitter end. And that's too late.

Crossing the Desert Syndrome

I'm close to falling into "Crossing the Desert" syndrome. A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they're not at the end of the project--they still have to finish the darn thing. They're living the Crossing the Desert syndrome.

The problem with focusing on an interim milestone (and too typically doing lots of overtime, late nights, weekends to meet the milestone) is that the team is burnt out once they've met the interim milestone. And you still need them to finish the project.

If you're a PM in this position, encourage people to take some time off. If they haven't been taking weekends, and if they've been working overtime, have people go back to a regular 40-hour week. NO extra time. If they've missed some holidays or vacation, have them take time now. You need people who have brain cells left in their heads, not people who are about to--or already have--made stupid mistakes.

Be prepared for people to be a bit down, even after they've met the milestone. Because they pushed so hard, they may not be able to see how much progress they made, or how good the product is. They may only be able to focus on what they didn't do. You may need to be a bit of a cheerleader.

You may need to replan the rest of the project. If people had to work like crazy to meet an interim date, chances are good that the rest of the schedule is too aggressive, too. Gather everyone in a conference room, hand them all yellow stickies, and ask them to organize how they can finish the rest of the project.

Make sure you acknowledge their hard work, refocus them on the last part of the project, and good luck.

---

I first heard of Crossing the Desert from Jack Nevison of Oak Associates.