Earned value, percent complete, and other measures of work performed on a project have always seemed useless. Perhaps that’s why I like Scrum so much–it only requires participants to estimate the hours of work remaining. Johanna Rothman wrote a short but important piece: Managing Product Development: There is No Such Thing as Percent Complete. While some of the comments are critical, I think they highlight the real challenges of giving a percentage. To pull out two:

The difference between Physical Percent Complete and Percent Complete needs to be clarified. On software projects where the delivered features are produced through Work Packages the comcept of Physical Percent Complete can be used. (Glen B. Alleman)

This is only a problem if you take the percentage as a percentage of time. A percentage of requirements fulfilled works just fine. (Michael Lucas Smith)

To be confident in % complete, you need to be confident in your estimates, in the amount of work completed, in the amount of work remaining, and in the speed at which the remaining work can be completed. That’s a lot of moving parts and merely watching the percentage change over time provides little insight into those underlying numbers.

When you ask a team member for percent complete, you’re generally only trying to learn two things: when will their work be completed and how will that timeline affect other parts of the overall project. Ask only the questions you need answered and you’re more likely to get the answers you need. The fact that it takes less effort to answer smaller and narrower questions is just gravy.

Photo by juliehicks75

Classic new product development starts with features, functionality, and quality. Customer needs are surveyed and researched, requirements are written, prototypes are designed and analyzed…and the entire effort is either time-boxed or budget-boxed, depending on the industry. Good companies know whether time or cost is more important, but those are generally secondary to actual functionality or final product qualities.

I’d like to propose that for emerging and innovation-driven markets–like high tech–features and functionality represent the least important corner of the triangle. I think that some of the most innovative companies start by specifying the cost and timeline for new product development, and take a more hands-off approach to actual functionality. Companies like Google and 3M, which explicitly require employees to devote time to personal projects (PDF) already do this. Events like Hackday are even more explicit.

The different product development focus looks a lot like Agile software development methodologies. Instead of asking, “What should our new product be?” it asks, “What cool things can we do cheaply?” I think this makes the most sense in innovation-focused markets because these are places where we know the least about what customers really want. The less you know about what customers really want, the less value you can expect to get from a product specification process. Agile methodologies, similarly, teach us that it’s unlikely you’ll get anything right on the first try, so you’d better make each iteration quick and cheap (Google cache) so that you can get it in front of a customer as quickly as possible.

Even though this kind of product development may make sense for technology companies, it will be seen as a challenge to the traditional product management role. Their job no longer consists of telling people what to do. Since essentially they’re being handed stuff (Engineer: “I noticed that with only a few more lines of code, our Wiki software would make a pretty good MS Project killer!”) they become advocates, influencers, cajolers,  and evangelists. It becomes a zen role: each new product becomes a surprise, an opportunity you cannot own, and a leap of faith to let others do what you had believed was your job.

The reward is profitability. The high-margin reward of being “first mover” can be overwhelmed by the sunk costs of the product development process. Explicitly starting by minimizing costs and decreasing cycle time means your margin of success is lower.

First, what are some problems facing students, teachers, and administrators could be solved through technology?

1. Students need help in document management and collaborative editing. Where’s the latest copy? What are the new changes? How do I combine everyone’s changes?
2. Faculty and administrators need to be able to change course schedules, syllabi, and assignments and be confident that students will see and understand those changes.
3. The career services office needs to inform students of new opportunities and upcoming  deadlines
4. Everyone needs to be able to hold conference calls and group chats.
5. No one wants to have to worry about the technology: “Do we all have the same IM client? Was that sent by email or posted on the bulletin board?”
6. Professors might want to have their lectures recorded, but limit viewing to students enrolled in the class, or to students with a documented disability or need.

Second, what sorts of functionality might be needed to solve those problems?

1. Asynchronous information distribution
• Text, like in a blog
• Audio or video of lectures, like with a podcast
2. Calendar information and schedule distribution
• Office hours for professors
• Campus and club events
• Job and internship application deadlines
• Free/busy information for rooms and resources
• Free/busy information for people
3. Document distribution and versioning
• Lecture notes and syllabi–how do you know if you have the latest version?
4. Address book and directory services
• Contact information: phone, email, postal, IM, websites, etc.
5. Real time communication
• Instant messaging and text messaging
• Voice chat
• Video chat
• Whiteboarding
• Document distribution
• Both one-on-one and group versions
• Transcripts and recordings available
6. Non-real time communication
• Emails
• Bulletin boards
• Voice mail
• Comments
7. Group editing
• Real time document editing
• Collecting and merging document changes
• Whiteboarding
• Wikis
8. Testing
9. Drop box for handing in assignments
10. Surveys, polling, and voting
11. Data analysis
• Summary statistics
• Pivot tables
• Data collection

Third, what are the restrictions and limitations placed on a technology solution:

1. Can a solution be branded or the appearance changed to match the institutions standards?
2. Will a solution be accessible?
3. Will users always know where to go for information or for a tool?
4. Will users be able to choose their client? Will Outlook be required? A specific browser? Some third-party tool?
5. Doe user access and role information need to be maintained?
6. What security needs exist?
7. How hard will end users need to work? How much education will they require to get started? How many steps or clicks will be needed to use the tools?
8. Where does the server need to be located?
9. Do the tools need to be accessible to people outside the domain or outside the firewall?

Finally, the development and deployment approach needs to be considered:

1. A monolithic or waterfall approach, where projects are properly scoped, spec’d, implemented, and tested before deployment
2. An iterative or agile approach where incomplete or inadequate tools are deployed to users as quickly as possible, and the users participate in frequent revisions and refinements.

While there are many reasons for the traditional waterfall approach, schools struggle because of their very high turnover (students change classes every semester and graduate after a few years). Furthermore, as schools can be extremely bureaucratic, an iterative approach also allows end users to feel more ownership over the product and might increase adoption.

So, what software? I’ve already begun a page on some free tools. But perhaps the best tools to use are the ones that you already own. Most people do not know how to use the collaborative editing features in MS Word: send for review and merge revisions. And most people don’t know how to use group calendars in Outlook.

In terms of easy ways to get your feet wet, it’s worth trying a blog system as a means of distributing information. Better than a news page, most blog software allows makes it easy to create items, to categorize items, and to have viewers subscribe. Not only is software like WordPress free, but there’s even software to easily manage multiple blogs. If you’re hosting the blog yourself, it should be no problem to include documents and multimedia files as enclosures, or you could use one of the many hosting services–some of which let you keep files private, are free, and have no size or bandwidth limits.

And there are lots more geeky tools. Google Calendar allows you to subscribe to calendars (such as class calendars, or club calendars) so there must be some way to do the same thing in Outlook. Developers have many options in version control software: there must be something that allows students to check in and check out documents and compare versions.

I’ve written about it before, but Tom DeMarco’s book Slack addresses this very issue. According to DeMarco, these sorts of interruptions are part of business. He likes Agile methodologies, but his solution is more straightforward: make sure your teams has enough Slack, the free time to do unscheduled and unplanned work.

1. If you’re going to go through a process more than once, build a tool and automate it.
2. You’ll never do anything just once.

That said, for many of us (particularly non-developers) there’s a substantial cost to building that tool. I’m not so good with Perl or Ruby or Visual Basic and often I’d find that the tool that took me so long to build didn’t really meet my needs. If I were a better toolsmith, I could just build one to throw away, learn from my mistakes, and build a second that’s better. Instead had to postpone the building, struggle with the manual process, and hope to use that struggle to really suss out the requirements for automation.

I think that organizations are in a similar situation: they’re often encumbered by too many manual processes and in need of better tools. But just like individuals, before you start building the tool it pays to know if you’re a good toolsmith. Organizations with those skills know to build their first version quickly, try it out, throw it away, and try again, learning from their mistakes. Most organizations, like most of us, are bad at building their tools. IT projects come in late and frequently don’t meet users needs. Does that sound like you? Don’t jump to build the tool, but take your time, pay attention to the manual process, and really understand what you’re trying to do.

(On reread, you could just think of the manual process as a first draft for people and organizations that aren’t good at developing software tools.)

“From Manufacturing to MIS and Medicine: The Theory of Constraints in Knowledge Industries”

“Limits of the Balance Sheet: How Financial Reports can Obscure Operational Problems”

“Aligning Operations and Strategy using the Discipline of the Project Triangle”

Which route is more efficient?

This isn’t really an SAT question – it’s a management question and it illustrates the problem with questions of efficiency and similar fuzzy concepts of effectiveness. My car gets about 33 miles per gallon at highway speeds. In stop and go congestion, though, my car’s only getting 15 MPG. Which is more efficient? In terms of total gas use, the numbers are reversed. The usual route will only use a gallon while the alternate will require almost 50% more. On a “gallon’s per commute” basis it’s better to sit in traffic. Of course, there’s also the issue of efficient use of my time – what’s the value of 15 minutes driving saved?

This is the same problem faced when juggling the trade off between project cost (typically a function of people hours worked) and project (calendar) time. Project management metrics can illustrate the problem and the trade offs but in the end it’s a matter of differential valuation of requirements: a matter of values.

(As an aside, it’s interesting that hybrid systems like the Toyota Prius tackle efficiency at both ends. A very small gasoline engine provides even better highway mileage while the low horsepower but high torque electric engine prevents wasteful idling and low-RPM movement in stop and go traffic.)

This concept is promoted by Eliyahu Goldratt and his Theory of Constraints and in his books like The Goal. He argued that in in the case of discrete manufacturing–where individual goods are produced in a continual but not continuous process through the discrete application of heterogeneous transformations–as the utilization (or efficiency) of the individual steps approaches their maximum, the productivity (or throughput) of the system as a whole approaches a minimum. Now, software development looks to me a lot like discrete manufacturing. You have a set of inputs of varying quality: requirements, best practice documents, etc. In a factory, the machines that perform a step in the manufacturing process often differ – they could be different models, have different maintenance histories, have different tolerances with regards to inputs or throughput, or produce at different levels of quality. Tom DeMarco reminds us that knowledge workers–and this includes the analysts, designers, developers, and engineers–are similarly not fungible. Not only does each individual have their own specialties and deficits but people have task switching costs analogous to the set up costs with factory machines.

While Slack was the first book I read to apply TOC methodologies to software development, I’ve been noticing that it’s not an uncommon perspective. The Agile Management Blog is thick with these ideas as is Steve Hebert’s Development Blog, the Creative Generalist, and Frank Patrick’s Focused Performance Weblog.

Using the TOC approach provides two primary advantages:

1. The opportunity to apply an empirical science to the fuzzy art of software development management–and a science tested in modern manufacturing industry.
2. A concrete and tested method for examining, evaluating, understanding and improving your development processes

As the name implies, a central tenet of TOC is the identification of your system’s primary constraint. Often called the bottleneck, this the step in your system that controls the maximum throughput, and systemic throughput, according to TOC, is the most important metric of effectiveness. As the constraint control the throughput of a system, no increase in resource utilization outside the constraint will increase systemic throughput. The only option, then, is to increase utilization of the constraint itself.

In the software world, the constraint could be code review by the lead architect. It could be sign off by legal. It could be client feedback. It could be any number of things. However, once the constraint is identified there are a limited number of available actions:

1. Add capacity to the bottleneck. Typically this means increasing the number of people who can perform the bottleneck task(s).
2. Ensure the bottleneck only does high quality work–improve the quality of its inputs. Before the architectural code review, code could be peer reviewed. The legal department could prepare guidelines or an inexpensive paralegal. Internal client surrogates could be used.

Remember, though, that these changes can possibly move the bottleneck. Code review is fine but QA is stalled. Client feedback is coming in fast and furious but issues are no longer being adequately prioritized. Moreover, resources cannot be added indiscriminately–there’s still a cost to task switching and adding resources to an already late project typically only increases the delay.

That’s enough out-loud thought for me. Something to think about – what limits your organization’s productivity? And what can you learn from other disciplines?

Here’s exactly how much I earn and what my bonus structure is. I’ve often wondered what would happen if corporations had transparent pay scales – public jobs often do (teachers, senators, police officers). No law prevents an employee from posting their paychecks on their office door. In specific to executives, knowing how they’re rewarded explains tons to their organization. Good VPs do communicate what their personal goals are, but knowing even the non-financial elements of their rewards (what are they rewarded on?) might be more useful to the organization that what’s in the project vision. (Of course, this would require that CEOs define the rewards. Begging for a list of “ten things CEOs never say”).

I did work at one, many years ago, and I liked it. The transparency wasn’t obvious–new financial reporting software allowed drill down to individual accounting transactions, which included payroll. Surprisingly, there wasn’t much animosity. A few folks who were dramatically underpaid received raises. Folks who had received comparatively low bonuses and raises seemed to move on a little faster. Beyond that, it just meant one less thing to speculatively gossip about. Overall, it was relaxing. On the other hand, it showed how low my salary potential was at the company, and hastened my departure. If you’re going to underpay, I guess maybe you should try to keep your employees in the dark.

My point, and I do have one, is that price is a signal, a story, a situational decision that is never absolute.

Yesterday I also said that most of your customers will be more sensitive to features and scheduling than price (and that those are the only three possible project requirements). Seth says:

And yet, Easy411 provides precisely the same service to callers for half the price. Why doesn’t everyone use them? Because it’s not just the price. It’s the hassle and the set up and the “I didn’t get around to it” nature of saving a few bucks.

Here’s everything Seth had to say: Seth’s Blog: Most people don’t really care about price. If Seth agrees, then I must be right!