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.

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?

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!

1. Understand how their company “makes money”–their corporate strategy for success and metrics for determining progress towards that goal
2. Be able to evaluate requirements (i.e., cost, schedule, and features) in terms of the above metrics and goals
3. Be able to cost and price and understand the difference between the two

What is the difference between cost and price? Why would price be different than cost? Cost is a description of the impact on your resources of doing something–of meeting a set of requirements. Price is a means for communicating your priorities and preferences to those whose requirements you are asked to meet.

From the perspective of managing a project, there are only three requirement: Cost, schedule, and features, and it’s accepted project management practice that only two of them can be specified at a time (as engineers say: “Better, faster or cheaper–pick two”). If you understand your corporate strategy you can help your customers understand which two are the most important. For example, in the retail financial services world, IT costs are often only a small part of the budget for a new product launch. However, the IT portion of the project can still be on the critical path–if the IT part is delayed or doesn’t meet the feature and quality requirements the opportunity cost is great. It would then be reasonable to assume that the sponsoring business group would be willing to pay a high premium–possibly above estimated costs–to guarantee that their feature and schedule requirements are met.

It’s not enough to be willing to adjust prices to meet feature and schedule requirements. You need to be operationally prepared to accept the work. This is done by maintaining a level of staffing slack above your expected work level. Your level of slack bounds your capacity to meet new requirements and new projects. How much slack is required?

That’s a harder question than deciding how much slack to pay for. One way to calculate it would be to identify the corporate cost of missing features or delaying delivery. The cost to the company should approximate the price they’d be willing to pay to avoid it, which is to say, the price they’d be willing to pay for slack.

Interestingly, it’s likely that maintaining slack across the team and the IT organization will probably lower overall costs, but my theory that IT is just discrete manufacturing probably deserves its own post.

Why can’t an organization be responsible for all of its IT needs? In most cases it would be absurd. Few companies write their own word processing or email software and few companies hand build their own servers. Why not? Three primary reasons:

• It’s relatively easy to specify accurate requirements for the products. For example: 2U, 2 CPU rack server, 4GB RAM, 137 GB HD in Raid 5 array, or, even easier, MS Office 2003.
• Your organization’s business plan and strategic objectives are unrelated to the specific requirements. Moreover, other organizations are looking for materially indistinguishable products: Office 2003 is Office 2003.
• Product improvements are do to a very large user base. The fact that Dell sells billions of servers or Microsoft millions of copies of MS Office means the cost of ongoing innovation can be spread across a large number of buyers.

These are fairly obvious examples – no one needs to justify purchasing off the shelf hardware or software for general business tasks. But what about more specialized tools? How well do my three criteria above work for your typical medium sized business:

• For the most part, specifying phone features isn’t so hard. Voicemail, call forwarding, conference calls, transfers, call parking, speed dial, temporary outgoing messages, number rollover, and number delegation should just about cover the software. On the hardware side, you should have speakers phone, handsets, headsets, independent volume for all three plus ring, multiple ring tones, and voicemail indicators. A small display to make dialing and menus easier would be highly desirable, and a larger display with soft keys to help navigation is a nice to have. That wasn’t so hard.
• Most company’s business plan doesn’t say, “We will leverage synergies and produce class leading value by installing the best gosh darn phone system in the world. That is, unless it’s your job to install phone systems or you run a call center. But hold that thought. The truth is, you don’t care if your closest competitors all use exactly the same phones as you – that’s not going to make or break your bottom line. In fact, if you plan to hire folks away from your competitor, if they don’t need to learn a new phone system you might get marginally more value if your system is exactly the same as the one they just left
• Finally, phone systems change over time. Hard as you might work today to build the perfect phone system, you may start missing features like VOIP, forwarding to cell phones, and the ability to listen to messages via email. If you’re responsible for building and installing the system, you’ll be the one responsible for upgrades.

Some organizations, of course, will care more about their phone systems than others. If you run a call center, your system is part of your workflow and presumably part of the value you offer your clients. You may not be the one to build and install it, but you would expect your IT group maintain some level of expertise in this critical product. Properly specifying the project will be a tremendous undertaking and you’re probably not going to get it right. You’ll probably end up with a customized solution. Moreover, compatibility with your workflow may be more important than the addition of new features over time.

Basically, the IT department, in terms of taking on new projects, should focus on those that will have the greatest impact on the organization. These will be the ones tied most directly to the organizations value proposition–it’s understanding of the means for success. Typically we can expect these to look similar: they will be difficult to specify and they will look markedly different than a similar product that your competitors would want.

Are you investing in the correct IT projects? Are you outsourcing the rest?