While we don’t get there 100%, though, I would argue that my program at Babson College gets closer than most other schools:

• Unlike traditional programs organized around a semester system, Babson eschews stand-alone courses for integrated, just in time knowledge delivery. Our first year is organized to follow the life-cycle of an archetypal corporation: evaluating the opportunity, assembling the team, developing the plan, securing funding, expanding operations, and becoming global. Subject matter such as finance, operations, and law are combined.
• Real-world experience is explicitly integrated. Every first-year student is required to complete a year-long consulting project for a local company. Many (if not most) second year students engage in unpaid, for-credit work projects: managing teams of undergrads, consulting for area businesses, managing the school’s endowment, or starting a business in the school’s incubator.

Babson is the entrepreneurship school. Most students don’t start their own companies but the focus throughout our two years is on identifying and realizing opportunities. For employers who primarily want someone to do valuations, or design marketing plans, of do cost accounting, we might not be the best choice. But for the sorts of businesspeople Seth Godin imagines, Babson could be just the right program.

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.

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?

I just got back from a week long business trip in Cape Town, South Africa. It’s a beautiful city, reminds me much of any US coastal city, but crime is a real problem. In any given year, one in 65 Capetonians will have something stolen from their car, one ins 239 will have their car stolen, and one in 4067 will be carjacked (cf. Crime in South Africa’s Metropolitan Areas, 2001, compiled by Mark Isserow). Compared to the rest of South Africa, a car is considerably more likely to be broken in to, but less likely to be stolen or carjacked. In fact, Cape Town is considered relatively safe with regards to violent crime. Even so, as in the US, it is the perception of crime that effects people’s behavior. (Anyone interested in South Africa and crime should peruse Institute for Security Studies’ SA Crime Quarterly.)

Due to this high crime rate, car guards are ubiquitous at every public parking place. In Cape Town, at least, most wear reflective bibs to for a veneer of professionalism. And, in most cases, the transaction seems extremely professional. They’ll guide you to a parking space (stopping traffic if necessary) and assure you that they’ll take good care of your car. No money is expected until you return. The expectation is that when you do return and see that your car hasn’t been burgled or vandalized you’ll tip them: 3-6 Rand seems typical, or between 50 cents and a dollar US.

I didn’t realize, until returning to the States, that most car guards or refugees from Congo, Zimbabwe, or another country in southern Africa. It’s likely that a car guard has completed secondary school and many attended college. They’ve found an entrepreneurial way to take advantage of their situation and the most abundant local resources: high crime rates and government failure.

This past January 3, 2006, American Public Media’s Marketplace aired a Youth Radio piece on car guards.

Our clients understand that our rates are a good value for the work we provide. Our clients also run businesses and understand that they in turn must make a profit. Raising your prices does not mean scalping. Raising prices ensures stability, excellence-in-work, and profitability for the future.

Pricing isn’t just a tool for completing and invoice or estimate. Pricing is a marketing signal. Pricing yourself low signals that you don’t value your work or consider your product above average. Customers who choose you for your price signal that they care less about your quality. A while back, I stated that an IT project has only three requirements: cost, functionality, and schedule, and that only two of those may be specified. Choosing your business’ product based on price signals that your client doesn’t care either about schedule or functionality (and quality is a function). Price yourself right, and you get the clients you want.

So, what are the competitive options for online personal or small business accounting? ePeachtree offers solutions starting at $150/year and only slightly more attractive than my bank’s website. Back in 2000. Juno Accounting is another aged-looking application starting at $330 per year.

There doesn’t seem to be much more for the individual. I found Chipcount ($26/year), fnCentral, mVelopes ($100/year), and ExpMan (not accepting new users).

A quick Technorati search yields one mention for Chipcount, 168 or so for mVelopes, and nothing relevant for ExpMan.

Frankly, I’m surprised. I’d expect in this always connected mobile world there would be more companies pushing simple online accounting or personal financial management software. At the very least where are all the bloggers looking for it? On the other hand, this could be a case of competing against “Excel and Post-Its”. I’ll be reviewing Chipcount and mVelopes over the next few weeks from a Web 2.0 usability perspective. In the meantime, please share your experiences with this sort of software.

Kiva works by partnering with private development NGOs to identify and screen individuals who could utilize small amounts of money ($25 – $500 dollars) to start or substantially expand their own small businesses. Kiva then provides a framework to allow anyone with a PayPal account to select one of these entrepreneurs and give some or all of the funds requested. The entire donated amount is given to the requester (Kiva supports itself through separate donations) and each entrepreneur agrees to pay back the full loan amount, interest free, in six to twelve months. Though it hasn’t happened yet, a defaulted loan becomes a tax-deductible contribution.

Do you have an extra $25 you could lend to someone in need? Can you afford to right off your $1000 tax refund? Consider socking your hard earned money away in Kiva and letting it do some good.

(via Treehugger and The Kiva Chronicles)

I think it’s to double-check your intuition:

Double check your intuition. Everyone has stories about the candidate that they “knew” wouldn’t work out who turned out to be a nightmare employee. Or the employee they “knew” would work out despite a lack of qualifications who turned out to be the employee of the decade. The problem with intuition is that people only remember when their intuition was right–truth be told, their intuition was probably wrong as often as right. My recommendation is that you ask every candidate the same questions and take extensive notes. You might even conduct the first interview by telephone so you cannot judge the candidates by their appearance. In particular, startup founders believe they have a good “gut feel” for candidates, so they conduct unstructured interviews that are way too subjective, and they end up with lousy hires.

Tom Foster has been hammering this point home on his Management Skills blog: when making hiring decisions, the only reliable predictor of future behavior is past behavior. Way back in December last year he said:

Here it is, then. Stop trying to play amateur psychologist, you are not qualified. Play to your strength. You can spot positive and negative behavior in an instant because you are a manager. Play to your strength as a manager. Especially during the hiring interview.

More recently, he suggests a technique for helping to determine, in an interview, if the candidate possesses the desired pattern of behavior:

“In the interview process,” I replied, “if the behavior is frequent, examples should come from the candidate easily. If you have to really probe and dig, it is likely the behavior is not frequent; in fact, the pattern of behavior may be only occasional, even rare. If this is a critical behavior for the position, you may have the wrong guy.

Too frequently, our hiring decisions hinge on fuzzy ideas like, “How well will the candidate fit with our existing team?” “Does the candidate share our organization’s values?” “Will the candidate bring the right attitude?” My wife is a clinician–she’s trained to evaluate and diagnose patients. Even so, her literature, coursework, and experience warn her that once initial diagnosis is made, even if it’s wrong, it’s very difficult to change. An untrained schlep like me? I’m totally unqualified to make any sort of psychological or personality assessment of a candidate after even a few hours interview. Why? Because our reality is subjective–and we generally see people as we expect them to be. Hiring based on personality equals hiring by guessing. Is this good hiring?

Our most important role as managers is recruiting and hiring. And you shouldn’t trust a random blog from someone you’ve never met. Try HIRING SMART by Pierre Mornell. He devotes too much time to psychological tricks (boo) but balances it by discussing the importance of getting concrete examples from the candidate and following up in a meaningful way with the references.