Product Management & Business Strategies

14 Key Principles for Project Management Success...

2008-05-02T10:39:00.000-07:00

Project managers must focus on three dimensions of project success. Simply put, project success means completing all project deliverables on time, within budget, and to a level of quality that is acceptable to sponsors and stakeholders. The project manager must keep the team's attention focused on achieving these broad goals.
Planning is everything -- and ongoing. On one thing all PM texts and authorities agree: The single most important activity that project managers engage in is planning -- detailed, systematic, team-involved plans are the only foundation for project success. And when real-world events conspire to change the plan, project managers must make a new one to reflect the changes. So planning and replanning must be a way of life for project managers.
Project managers must feel, and transmit to their team members, a sense of urgency. Because projects are finite endeavors with limited time, money, and other resources available, they must be kept moving toward completion. Since most team members have lots of other priorities, it's up to the project manager to keep their attention on project deliverables and deadlines. Regular status checks, meetings, and reminders are essential.
Successful projects use a time-tested, proven project life cycle. We know what works. Models such as the standard ISD model and others described in this text can help ensure that professional standards and best practices are built into our project plans. Not only do these models typically support quality, they help to minimize rework. So when time or budget pressures seem to encourage taking short cuts, it's up to the project manager to identify and defend the best project life cycle for the job.
All project deliverables and all project activities must be visualized and communicated in vivid detail. In short, the project manager and project team must early on create a tangible picture of the finished deliverables in the minds of everyone involved so that all effort is focused in the same direction. Avoid vague descriptions at all costs; spell it out, picture it, prototype it, and make sure everyone agrees to it.
Deliverables must evolve gradually, in successive approximations. It simply costs too much and risks too much time spent in rework to jump in with both feet and begin building all project deliverables. Build a little at a time, obtain incremental reviews and approvals, and maintain a controlled evolution.
Projects require clear approvals and sign-off by sponsors. Clear approval points, accompanied by formal sign-off by sponsors, SMEs, and other key stakeholders, should be demarcation points in the evolution of project deliverables. It's this simple: anyone who has the power to reject or to demand revision of deliverables after they are complete must be required to examine and approve them as they are being built.
Project success is correlated with thorough analysis of the need for project deliverables. Our research has shown that when a project results in deliverables that are designed to meet a thoroughly documented need, then there is a greater likelihood of project success. So managers should insist that there is a documented business need for the project before they agree to consume organizational resources in completing it.
Project managers must fight for time to do things right. In our work with project managers we often hear this complaint: "We always seem to have time to do the project over; I just wish we had taken the time to do it right in the first place!" Projects must have available enough time to "do it right the first time." And project managers must fight for this time by demonstrating to sponsors and top managers why it's necessary and how time spent will result in quality deliverables.
Project manager responsibility must be matched by equivalent authority. It's not enough to be held responsible for project outcomes; project managers must ask for and obtain enough authority to execute their responsibilities. Specifically, managers must have the authority to acquire and coordinate resources, request and receive SME cooperation, and make appropriate, binding decisions which have an impact on the success of the project.
Project sponsors and stakeholders must be active participants, not passive customers. Most project sponsors and stakeholders rightfully demand the authority to approve project deliverables, either wholly or in part. Along with this authority comes the responsibility to be an active participant in the early stages of the project (helping to define deliverables), to complete reviews of interim deliverables in a timely fashion (keeping the project moving), and to help expedite the project manager's access to SMEs, members of the target audience, and essential documentation.
Projects typically must be sold, and resold. There are times when the project manager must function as salesperson to maintain the commitment of stakeholders and sponsors. With project plans in hand, project managers may need to periodically remind people about the business need that is being met and that their contributions are essential to help meet this need.
Project managers should acquire the best people they can and then do whatever it takes to keep the garbage out of their way. By acquiring the best people -- the most skilled, the most experienced, the best qualified -- the project manager can often compensate for too little time or money or other project constraints. Project managers should serve as an advocate for these valuable team members, helping to protect them from outside interruptions and helping them acquire the tools and working conditions necessary to apply their talents.
Top management must actively set priorities. In today's leaner, self-managing organizations, it is not uncommon for project team members to be expected to play active roles on many project teams at the same time. Ultimately, there comes a time when resources are stretched to their limits and there are simply too many projects to be completed successfully. In response, some organizations have established a Project Office comprised of top managers from all departments to act as a clearinghouse for projects and project requests. The Project Office reviews the organization's overall mission and strategies, establishes criteria for project selection and funding, monitors resource workloads, and determines which projects are of high enough priority to be approved. In this way top management provides the leadership necessary to prevent multi-project log jams.

Are Internet Companies Overvalued (Again)???

2008-04-30T11:24:00.000-07:00

What we can learn from eBay’s acquisition of Skype.

In September 2005, eBay Inc. acquired Skype Technologies, an unprofitable Internet protocol–based voice telephony company, for US$2.6 billion in cash and stock (as well as earn-outs, which potentially provide the sellers with additional revenue if the company meets certain financial performance targets; in this deal it could increase the purchase price to $4 billion). This transaction marked the beginning of a new wave of Internet industry mergers and acquisitions following a long, painful correction. Other major deals since the eBay–Skype deal have included Google’s acquisitions of DoubleClick and YouTube, Microsoft’s acquisition of Aquantive, and News Corporation’s purchase of MySpace. In fact, more than 1,150 technology transactions worth more than $30 billion have closed since — many featuring lofty valuations, considering that most of the acquired companies had short operational histories and limited or nonexistent earnings.

There is a very strong chance that, to a large degree, acquirers are overpaying either because of limitations in common techniques for placing a value on mergers and acquisitions or perhaps because of a lack of investment discipline in firms with excess cash. For example, one of the more popular valuation methods is discounted cash flow, in which all future cash flows from an acquired company are estimated and then “discounted” to give them a present value. But the outcome of the analyses in many of these deals is often little more than a guess, especially when there is not enough history about the company being acquired or a sufficient number of comparable firms to determine with any degree of accuracy what its next ten years will be like. If the revenue assumptions or synergy estimates are too aggressive, then the buyer has overpaid. Another way of approaching valuation is by comparing previous similar transactions. But here, too, the record is small or insufficiently applicable to be credible.

Therefore, in addition to these somewhat lacking models, we recommend that today’s dealmakers also use a real options framework, which seeks to analyze and value the options, or strategic alternatives, that a company will have once it acquires another company. Although this method also depends on some assumptions, the rigor of building this type of analytical framework makes it much less vulnerable to pure guesswork and is an excellent way to determine the efficacy of management assumptions. We applied this approach to the eBay–Skype deal because it is the oldest of the recent wave, enabling the analysis of several quarters of financial data, eBay management’s long-term plans for Skype, and Wall Street analysts’ financial projections.

Several premises drove eBay’s acquisition of Skype.

eBay was facing a slow-down of its core business in a maturing online auction market.
eBay management had achieved previous success in its diversifying acquisition of Paypal, which allows purchases and money transfers to be completed online.
“Convergence” would rapidly eliminate differences among separate Internet-based businesses.
Direct competitors were rumored to be interested in buying Skype.
Skype’s Voice over Internet Protocol (VoIP) communications capabilities would transform the way people make and receive calls.

Consequently, eBay management was convinced that Skype would accelerate trading on eBay by letting buyers and sellers communicate over the Internet; Paypal integration on the Skype system would allow easier payment methods for users; Skype could promote eBay services, and vice versa; and the acquisition would enable eBay to pursue entirely new businesses such as pay-per-call.

In our assessment, a discounted cash flow analysis of the core Skype business, under fairly aggressive assumptions, yields an enterprise value of only about $1.5 billion, $1.1 billion short of the purchase price. To arrive at this, we conducted a strategic analysis of the VoIP landscape to review eBay’s assumptions for long-term operating margins as discussed in publicly available merger materials. Our review identified significant areas where eBay appears to have been overly optimistic — especially given the highly competitive VoIP landscape as startups, large Internet companies, and incumbent telecom/cable companies enter the industry. For example, eBay assumed 20 to 25 percent long-term operating margins versus a more realistic 15 percent. We also took Wall Street analyst projections for the Skype unit and conducted multiple discounted cash flow analyses that covered several potential scenarios, from best case to worst.

Because the discounted cash flow analysis clearly showed that eBay’s rosy forecasts had led the online auctioneer to a higher valuation than Skype was likely worth, we then examined whether a combination of real options for the future, including potential growth in new business areas such as pay-per-call services and mobile payments, as well as the possibility of eventually combining and divesting assets, could be used to justify the additional $1.1 billion that eBay paid.

However, the real options analysis was less than promising: We found only a limited chance that Skype would help eBay grow its business beyond what it would be without the acquisition or that the combination would allow eBay to streamline its operations. Given the gap between our discounted cash flow and real options value and what eBay paid, even aggressive synergy assumptions representing 5 to 10 percent of the purchase price, or $130 million to $260 million, were not enough to justify the premium. In addition, this amount would be offset (partially or fully) by the costs associated with diversification and the cross-border nature of the deal. (Skype is based in Luxembourg.)

We thus concluded that in the eBay–Skype deal reality fell short of the hype. The premium could be justified only if very dubious assumptions were used and competitive dynamics were ignored — the latter especially questionable in a volatile industry such as telecommunications. Furthermore, our analysis concluded that merely forming a partnership with a company like Skype, or building auction-related VoIP services internally, might have been sufficient to provide eBay with entry into new businesses that it hopes to gain from the Skype acquisition. Finally, the sustainability of any competitive advantage was far from guaranteed, which also undercuts the logic of the deal. Therefore, although the acquisition might have embodied an acceptable diversification strategy for eBay, the assumptions used to validate the purchase price appear to be overly aggressive and are difficult to justify through any combination of valuation models.

We are not arguing that all the recent Internet transactions are flawed. The acquisitions of DoubleClick and MySpace, in particular, appear to have been smart moves. However, we are raising the question whether overpayment in many of these deals is destroying shareholder value. In fact, we wonder whether, as has happened in other mature industries, excess cash and nonoptimal capital structure have fostered a lack of management discipline or even management hubris. Another potential explanation for the high values in these deals could be the intense competition for assets among a small number of large players. Executives in technology companies must make fast and risky M&A decisions in uncertain environments because industry rivalries are so intense. But there are real trade-offs that must be considered, namely the “gambling with house money” syndrome.

It was precisely this syndrome that fueled the first Internet bubble. We should remember that a sign of the end of the first bubble was highly speculative transactions. It is now pertinent to ponder whether some acquisitions of the current era will ever realize their transformative promise. Irrational exuberance, the phrase made famous by Alan Greenspan, may once again be raising its frothy head.

Put The 'E' Into Your Marketing

2008-04-29T10:50:00.000-07:00

E-marketing and the e-tools used should be part of the overall marketing strategy for a business, integrated and supporting the more traditional methods of marketing, and vice-versa. Used together, the e-tools outlined here constitute a powerful marketing approach for any company. They complement one another and each one serves to build and support upon the success of the other tools. E-marketing is now the norm for companies wishing to capture the attentions of their target market. The degree of importance placed on e-marketing can be judged by the corporate spend in this area and the increase in spend which will occur going forward. E-marketing is within the budget of all businesses and should be part of the strategic business plan.

A number of factors affect the propensity of companies to incorporate e-marketing tools into their marketing mix. Few of these are:

The time needed to devote a consistent effort and approach to e-marketing.
How familiar on a personal level individuals are with the various e-tools.
Unsure of how to define the strategy for using e-marketing; objectives, design and implementation, delivery and measurement.
Understanding of how e-marketing and traditional marketing integrate and work together.

There are 7 functions of the eMarketing that stay at the base of any eMarketing strategy and they have a moderating character, unlike the classic Marketing mix that comprises situational functions only. These are:

1. Personalization

The fundamental concept of personalization as a part of the eMarketing mix lies in the need of recognizing, identifying a certain customer in order to establish relations (establishing relations is a fundamental objective of Marketing). It is crucial to be able to identify our customers on individual level and gather all possible information about them, with the purpose of knowing our market and be able to develop customized, personalized products and services.

2. Privacy

Privacy is an element of the mix very much connected to the previous one: personalization. When we gather and store information about our customers and potential customers (therefore, when we perform the personalization part of the eMarketing mix) a crucial issue arises: that of the way this information will be used, and by whom.

3. Customer Service

Customer service is one of the necessary and required activities among the support functions needed in transactional situations.

4. Community

We can all agree that eMarketing is conditioned by the existence of this impressive network that the internet is. The merely existence of such a network implies that individuals as well as groups will eventually interact. A group of entities that interact for a common purpose is what we call a "community" and we will soon see why it is of absolute importance to participate, to be part of a community.

5. Site

We have seen and agreed that eMarketing interactions take place on a digital media - the internet. But such interactions and relations also need a proper location, to be available at any moment and from any place - a digital location for digital interactions.

6. Security

The "security" function emerged as an essential function of eMarketing once transactions began to be performed through internet channels.

7. Sales Promotion

At least but not last, we have to consider sales promotions when we build an eMarketing strategy. Sales promotions are widely used in traditional Marketing as well, we all know this, and it is an excellent efficient strategy to achieve immediate sales goals in terms of volume. This function counts on the marketer's ability to think creatively: a lot of work and inspiration is required in order to find new possibilities and new approaches for developing an efficient promotion plan. On the other hand, the marketer needs to continuously keep up with the latest internet technologies and applications so that he can fully exploit them.

To conclude, we have seen that eMarketing implies new dimensions to be considered aside of those inherited from the traditional Marketing. These dimensions revolve around the concept of relational functions and they are a must to be included in any eMarketing strategy in order for it to be efficient and deliver results.

Product Lifecycle Management Promises to Streamline Development, Boost Innovation

2008-04-29T10:25:00.000-07:00

Build profitability and sustainable growth into your new products.

Successful new products are the lifeblood of your company’s growth and profitability. The success of 60% of most new products is determined in the product development phase, including 80% of costs and 90% of regulatory risks. Supplier collaboration early on can improve your product’s capabilities, as well as minimize costs and time to market.

Infor PLM (Product Lifecycle Management) helps your business maximize profit by optimizing every stage of your product’s life from portfolio management to product development to ongoing maintenance and retirement. It integrates product information from design and engineering with sourcing, compliance, suppliers, and supply chains to speed product development, ensure quality, and mitigate regulatory risks.

* Improve product innovation

* Drive revenue growth with successful new product introductions

* Boost new product profitability by up to 10%

* Reduce time to market by up to 50%

* Improve on-time product launches by up to 98%, including regulated industries

Infor PLM is a web-enabled product lifecycle management system that is used by enterprising companies around the globe to transform products into profits. Capable of integrating with leading CAD/CAM software and ERP systems in multi-company and multi-site environments, it includes the following key components:

Integrated PLM—a set of integrated project, portfolio, and research and development (R&D) applications that speeds development of new products and variations by managing all aspects of the project, and minimizing time to knowledge though information transparency and analytics.

Product Data Management (PDM)—tools that streamline new product development and variations by facilitating secure access to a single source of the truth for accurate product information including drawings, formulas, bills of material, engineering change orders, and the like.

Collaboration—seamless integration of customers, suppliers, and/or partners to shorten time to market, reduce costs, improve quality, ensure compliance, and increase innovation

Facebook Case Study: Offline behavior drives online usage

2008-04-28T03:33:00.000-07:00

"Written by Nisan Gabbay"

Facebook was launched in February 2004 by Harvard undergrad students as an alternative to the traditional student directory. Its popularity quickly spread to other colleges in the US by word of mouth, and the site now registers close to 15M monthly UVs and over 6B page views per month. Facebook has completed two rounds of venture financing at very high valuations, the first at a valuation of ~$100M and the second at ~$550M (valuations are unconfirmed). These valuations were driven by the multiple acquisition offers that Facebook has reportedly turned down (the latest was a rumored $750M offer). Facebook is already generating significant revenue, so despite all the valuation and web traffic metric hype, it has also established a very real business.

Interviews conducted: Noah Kagan, early product manager for Facebook. Noah will soon release an e-book on Facebook, with good insight on the social networking space. You will be able to download the book at Noah’s blog, okdork.com. I have had plenty of informal conversations with people close to Facebook over the last two years, while not formal interviews, I would regard these as quality sources – employees, investors, and competitors.

I would also like to thank Nick Macey, a student at the University of Utah for helping in the research and writing of this case study, and providing the ever valuable user perspective as a current college student. Nick will be helping with some of the writing on Startup Review in the future.

--------------------------------------------------------------------------------

Key success factors

Provide pre-existing offline community with a complementary online service

Facebook had its initial success with college students by providing an information service that was not available offline – an interactive student directory containing each student’s class schedule and social network. Before Facebook added the feature sets it has today, it was simply a more complete student directory. Facebook did not create a community where one never existed before; rather they provided an important information and communication service to a pre-existing offline community.

While students already had a loose affiliation with all fellow students at a college, they didn’t have an easy way to learn more about their fellow students outside their direct social network. Given the large class sizes at most universities today, students don’t have the opportunity to interact with very many of their fellow classmates during class. I remember the days I spent at Berkeley in 200+ student lecture halls scanning the crowd for attractive girls or previous acquaintances. Facebook organized students by class schedule for the first time, making it possible to learn more about that classmate you might have a crush on. Although I am highlighting one particular use case, initial Facebook usage was indeed driven by dating type activity – checking people out, learning more about crushes, light stalking type of activity, etc.

The larger picture here is that Facebook created a high utility online service for enabling pre-existing social behaviors within an offline community. This makes for an interesting lesson learned: it’s easier to piggyback off a pre-existing community with offline behaviors that drive online service usage.

Restrict user registration (and other behaviors) to build desired online service

Facebook made important product decisions that ensured harmony and trust between the offline community and the online service created. Facebook originally limited membership to those users who could verify they had a “.edu” e-mail address for the college they attend. Facebook also placed limits on the ability to search or browse users to the college that the user attends. These measures aim to make users feel that the site is exclusive and limited to members in their offline community (colleges and universities). In the early days of Facebook, something like 30% of users actually posted their cell phone number on their profile. I’m not sure whether this statistic is still valid, but it supports the notion that users trust who is viewing their profile.

Facebook has recently opened its doors to users outside the .edu networks. To accomplish this, they have created “networks”. High schools, employers and geographic areas are, essentially, what colleges were to the original Facebook. When you join one of these “networks,” you can only view others in the self-designated network. Additionally, Facebook has implemented a number of privacy controls that allow users to control exactly who gets to see the information they provide.

Aggregation of a series of deeply penetrated micro communities

Facebook is a more compelling advertising opportunity than other social networking sites because of deep penetration within a series of micro communities (college campuses). If a local advertiser wants to target a particular college campus, Facebook is the best way to get the advertiser’s message to that audience. CPM rates for local advertising command a significant premium from advertisers because of their more targeted nature. With 65% of users logging in daily and 85% weekly, advertisers can run time-oriented campaigns very effectively. The large, branded advertisers, who value reach, can advertise to nearly every student in the 18-22 demographic in the US with one campaign.

Facebook will have ample opportunity to diversify its revenue streams beyond traditional banner advertising due to its deep penetration in these micro communities. Having the attention of 90% of students attending a university lends itself to online classifieds, event listings, e-commerce, and lead generation. Facebook should be well-positioned to be a major player in online classifieds given the usage patterns of its user base.

Built strong brand recognition amongst user base and advertisers

The key to an online advertising business targeting branded advertisers (advertisers looking for branding, not just clicks) is having a strong brand that advertisers want to be associated with. A perceived hot brand is what drives premium CPM rates. Two sites having similar demographics and user usage patterns may have drastically different CPM rates based solely on the perceived brand recognition and image factor. While some people I spoke with disagreed, I believe that Facebook did a masterful PR job - highlighting the impact that Facebook has made on the lives of college students and their online media consumption in nearly every story written. How often do you hear that 90% of Facebook users login to the site once per week? Clearly the PR coverage came as a result of the tremendous viral growth, but capitalizing on that PR to help build brand was a key success factor.

Founder(s) credibility with college audience

The “face” of Facebook is Mark Zuckerberg. Back in February 2004, when Facebook was founded, he was a student at Harvard. Two other students, Dustin Moskovitz and Chris Hughes were the second and third employees of the company. This added a level of credibility to the site in the minds of the student users. It was something one of them had created, not something fed to them by a “company” in the traditional sense. It was a place that they could trust because one of their own had made it.

Adding to the underground feel of Facebook was the viral spread of the site. It fanned out throughout Boston, and then the Ivy League. Students at other schools had to wait in line until Mark and friends could find time to add their school. This created even more buzz around the product.

--------------------------------------------------------------------------------

Launch strategy

Prior to launching Facebook, Mark Zuckerberg had experimented with a number of different web products. In fact, his first attempt targeted at the Harvard student body was called FaceMash, which drew criticism from the University and some students, prompting Mark to drop the service.

Mark launched Facebook (at the time called thefacebook.com) in February 2004. Once the site was ready for users, the Facebook founders blasted e-mails to Harvard students to let people know about the site. The team had access to the e-mail addresses of Harvard students at each dorm. Thus e-mail marketing, viral feature sets, and word of mouth was how Facebook was launched. Given the immediate positive reaction that Facebook received at Harvard, Facebook began rolling out the service to other universities. Facebook did not use a targeted geographic roll-out strategy in the early days, they received registration requests from students at other schools, and then prioritized which schools to open based on the number of these requests. Interesting to note that this is how Craigslist rolls out to new cities – based on user requests.

From what I understood, Facebook did not receive any help from the schools themselves to promote the Facebook site to the student body. If anyone has evidence to the contrary, please leave a comment below.

--------------------------------------------------------------------------------

Exit analysis

There has been much speculation in the blogosphere and mainstream press regarding who will buy Facebook and for what acquisition price. I have heard from reliable sources that Facebook did indeed turn down acquisition offers for ~$750M earlier this year. Recent reports have claimed Facebook is in acquisition talks with both Yahoo and Microsoft for ~$1B. Is such a lofty valuation for Facebook justified? It all depends on an evaluation of future growth prospects, but I think that there is a misconception in the blogosphere that Facebook is not generating much revenue. On the contrary, Facebook was generating almost $1M per week in advertising revenue in Q1 2006. It is likely that Facebook will generate ~$50M in revenue in 2006, up from ~$10M in 2005. Some reliable sources believe that Facebook will do ~$200M in revenue in 2007. Given that Facebook has been guaranteed $200M in revenue over three years by the Microsoft advertising deal, the 2006 and 2007 revenue numbers seem attainable. If the 2007 revenue goal of $200M is reasonable, a 5X forward revenue multiple does not seem to be an excessive valuation multiple.

Many people also point to the fact that Facebook is considerably smaller than MySpace from a site traffic perspective and hence should have a lower valuation than the ~$500M that MySpace was purchased for. This type of comparison based on unique visitors and page views is clearly flawed because not all page views are created equal. There are several good reasons why Facebook’s page views are more valuable than those of MySpace:

1) Facebook’s core user base (college students) is more desirable than MySpace’s core user base (teenagers). Because college students have more disposable income and are more likely to have credit cards than teenagers, they are more desirable from an advertiser perspective.

2) Facebook represents a more compelling local advertising opportunity than MySpace because Facebook can guarantee deep penetration of college campuses, whereas MySpace cannot show the same types of local market usage patterns. The CPM rates for local advertising campaigns are typically substantially higher than national campaigns because of their more targeted nature.

3) Facebook is viewed as a safer option than MySpace for branded advertisers, as Facebook has a less racy image than MySpace. In a market where advertisers are still hesitant regarding user generated content sites, Facebook has done a better job of brand positioning.

Another noteworthy part of the Facebook story is how they masterfully handled the VC financing process, limiting the amount of equity dilution to the founders. When Facebook raised its first VC round of financing in April 2005, they negotiated a pre-money valuation of ~$85M at a time when they were generating less than $500K per month in revenue. Facebook was able to command such a high valuation by courting both VCs and potential acquirers simultaneously. With term sheets in hand to be acquired for $85M, Facebook was able to drive up the pricing on the VC round. I remember discussing with VCs who participated in the bidding for that first round how the price, which originally started at a $20M pre-money valuation, just kept climbing week after week until Accel Partners finally won the deal at ~$100M post-money. Hats off to Accel Partners for accurately assessing the potential of Facebook in those early days. The prevailing wisdom from other VCs was that Facebook would probably be capped at a $200-300M exit, and hence a 2-3X return was not high enough to justify the risk, given the youth and inexperience of the Facebook founders. Accel is likely to make a 8-10X return on its initial $13M investment in just 2 years. Facebook’s most recent $25M round was rumored to have taken place at a $550M valuation after turning downing a $750M acquisition offer. Once again, the Facebook management did a great job of creating a competitive environment for their second VC round. The one piece of information I would be curious to know is how Facebook’s $500K seed round of financing was structured. That investment was done at the end of 2004 by ex-PayPal exec Peter Thiel (when Facebook was available on ~30 campuses). I’m guessing that $500K bought 5-10% if it was structured as equity, but would have bought considerably less if it was structured as convertible debt. If anyone can shed some light on the seed round, please leave a comment below.

--------------------------------------------------------------------------------

Food for thought

The Facebook success story is most interesting to me because of how daily offline social behavior drove usage of the site. There are plenty of activities in our daily life that could benefit from a complementary online product. However, if that offline behavior only occurs once every few months, you have the challenge of user recall. Namely, will users remember your service and know how to find it to fill their need. Facebook demonstrates you have a great Internet service if offline behaviors can drive nearly daily usage online. In the life of a college student, you are meeting or interacting with new people nearly every day. It is human nature to be curious to learn more about that person, hence you jump on Facebook. Facebook fills a high value need for college users on a nearly daily or weekly basis, consistently reinforcing the utility of the service, and building goodwill with users. The issue of user recall is an import one for a web entrepreneur to understand, particularly if the need they are addressing occurs infrequently in the lives of their target users.

Another lesson that Facebook reinforces is the importance of brand and PR buzz to advertising rates. The amount branded advertisers are willing to pay for online advertising is hugely subjective – it’s still more art than science. To get premium CPM rates, entrepreneurs must establish a brand – not only with users, but also with advertisers. Many social services do not have high click thru rates on ads because people are not in the mind frame of looking for information when they are using a social service. All social networking sites suffer from this “lack of click thru” problem. While immersive advertising opportunities will eventually displace banner advertising on most social services over time, for the time being, traditional banner advertising is still a critical revenue stream.

Finally, we can learn a lot from Facebook by how they built initial trust between users and their service. While these days it is easy to build a consumer Internet product, establishing trust with users is not. As an entrepreneur, how quickly you can establish trust with your users can be a critical success factor. Facebook built immediate trust via the home page by showing only a select few colleges as being open to registration. Coupled with the registration process, users immediately understood that the site was exclusively for use by college students. This made them feel comfortable disclosing information that people normally wouldn’t post on the Internet. Simple, but very powerful. Facebook does give users control over the information displayed on their profile and to whom it is displayed, but only a small percentage of users actually change the default settings. Thus, the key part of the trust equation is not features, but branding and messaging about the service and who uses it.

--------------------------------------------------------------------------------

Reference Articles

“Facebook’s Critical Success Factors”, on Fred Stultzman’s blog Unit Structures, May 17, 2006

Great blog post that discusses 5 key success factors for Facebook. Unlike my analysis, this post has some detail on features that made the product sticky.

“Facebook - The Complete Biography”, written by Sid Yadav on Pete Cashmore’s Mashable! Blog, August 25, 2006

A detailed overview of Facebook from many perspectives, but provides a particularly in-depth look at the product itself.

“Inside Facebook: Life, Work and Visions of Greatness”, an e-book by former Facebook engineer Karel Baloun.

I thought the book was an interesting read from a human interest and start-up culture perspective, but could have discussed the company more from a business perspective. There is some good discussion on the vision and future direction for Facebook, how the company does and will make money, and how they’ve built trust with users.

“Dot-Com Bubble: Why It’s So Hard to Value Social Networking Sites”, from Knowledge@Wharton (University of Pennsylvania business school), October 4, 2006

Article has a good discussion on how to value Facebook and social networking sites. This article serves as a source for valuation and revenue numbers.

“Facebook on a roll, stay tuned”, by Matt Marshall on SiliconBeat blog, August 29, 2005

Has some good insight and quotes on why the site has been successful

Increase Your Website’s Page Rank

2008-04-28T03:23:00.000-07:00

As competition among websites increased, attention turned to the search page rankings in major search engines. Since ranking highly for specific keywords could “make or break” a business, webmasters started looking for any method to increase their ranking. By examining the algorithms of Google and other search engines, it became clear that a high value was being placed on the number and quality of links pointing to a website. As a result, most webmasters realized the importance of finding partners to link to their internet business.

This came about as a result of the Grand daddy of all search engines Google begun to implement its concept of “Page Rank” to classify websites in terms of their importance and perceived authority. Essentially Google defined links from any given website as a vote or endorsement of the site pointed to - the more significant the originating site, the more significant the endorsement. This in turn affects search engine results position as Google’s ranking algorithm gives significant weighting to this ratio.

To webmasters in search of ever more traffic, Page Rank or “PR” thus became an all important factor in choosing link partners, with the original purpose for linking getting lost in the stampede – helping your visitors navigate the net more easily.

Now the best way of doing this is by purchase of text links.

In this go to a text link broker and look for sites that are relevant or a good complement to your website’s subject material. The broker will tell you about:

The cost of purchasing that link.
The kind of website it is.
What all content it will support etc.

Benefits or buying or renting links:

This ensures one way link, which is better than Reciprocal link.
If you buy from a website which has a better PR, your PR also increases.
Also a link from a high PR website can provide a huge boost to your visitor traffic, as they typically have a large volume of people who regularly visit their site, giving your website’s url a large amount of exposure, increasing your chances of attracting more traffic

These are a few benefits of purchasing a link from a High PR website for you. Make sure that you follow this for your website because this will definitely boost your website and give it a High PR.

Recipe to Successful Product Development

2008-04-28T01:57:00.000-07:00

Ideas are funny like things, they won’t work unless we do”- I had read this small yet powerful statement inscribed on a small piece of wooden artifact during my visit to a successful entrepreneur’s office. I could never understand the depth and efficacy of this statement till I moved on to the big business of software product development. It was a lifetime experience to see a product evolving out of a myriad of ideas, which had no basis for existence or evolution. But what went behind the evolution of the product from a naïve idea was an endless passionate journey of pain and pleasure, which led me to conclude – “Behind a successful product; there are only a handful of passionate and committed enthusiasts”.

This article is a small effort towards sharing my thoughts on how to build that small yet powerful team of passionate people who translate small weird, funny ideas into million dollar products.

Keep it small

Start by building small teams of 3-4 people. Small teams instill great sense of togetherness and belongingness amongst the members. It breaks all the barriers of formality, hesitation, and hierarchy and establishes a highly collaborative environment – an important ingredient for success.

Sign – up people to the common vision

Ensure that every member in your team has signed up for the cause for which the organization exists. A team where people put personal agenda before organization objectives can never succeed.

Translate individual aspirations to product objectives

Understand every team member’s short term and long term career aspiration. Allocate a role on an ongoing basis based on his aspirations that can help the organization meet its product objective.

Build owners and not executors

Don’t hire people to delegate and execute tasks. It only creates an autocratic and bureaucratic environment. Build owners who can take responsibilities with great sense of ownership and with great feeling of empowerment. The sense of ownership is electrifying. It infuses great amount of energy and enthusiasm in an individual, which propels an individual to his maximum potential.

Encourage free flow of ideas

Set up an environment where people can express their ideas without any hesitation or fear. Remember, a true product development environment is one, which becomes a heaven for innovators and creators.

Build Transparency

Build a transparent environment. Share the success and failures of your organization in a transparent manner. Let your team be your biggest critique or biggest admirer. Actively seek their opinion in an open forum on various issues concerning the welfare of your organization.

Build killer instinct

A true product development team comprises of people who go behind their dreams with a killer instinct. They are go-getters. Transform your team to wear this attitude in life and you will never worry about the outcome.

Hear Customer’s Voice

No business in the world can succeed if the organization is not receptive to customer’s needs and desires. Make every person in the organization sensitize and orient towards a customer’s need. Only a receptive team can deliver a million dollar product to the organization.

Find your desert warrior

Always look for an individual who can sail you through the odds of business lifecycle – your desert warrior. If you can’t find one, then groom one.

Own the product from conception to completion and beyond

2008-04-27T11:46:00.000-07:00

Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup told me that my approach to product management was “very academic” in nature. He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a”get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products!

And while product managers have a direct responsibility in some of these 10 areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process. I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning
From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences. This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference. This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data. One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it. The documentation for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager. Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good. Don’t get me wrong. But not when it comes at the expense of the product being built.

Get your hands good and dirty
During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear
Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

· Are the salespeople on message?
· Are the sales consultants adequately trained?
· Do the demos hit on target?
· Is the market need that you researched and identified oh so long ago, still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.

Do Product Managers need Domain Knowledge?

2008-04-27T11:37:00.000-07:00

Do Product Managers need Domain Knowledge?

As part of the second Pragamatic Marketing blogfest, I’m responding to Steve Johnson’s post: “Everyone needs to know what we do here“.

In it, Steve writes about the need for domain knowledge for technology workers, particularly in regards to the business they are in and the needs of their market. Whether talking about engineers, marketers, sales people or product managers, everyone needs to understand the company’s strategic objectives as well as some aspect of market dynamics.

In this case, I can’t really argue too much with Steve. If key people in a company don’t have domain knowledge, then the question “Why not?” must be answered. Do your competitors have domain knowledge? Most likely, especially if they are leading you in the market. How can anyone run any kind of successful business without domain knowledge?

For technology companies, the questions to consider revolve around defining exactly what “domain knowledge” is, and how best to acquire and maintain it.

Domain knowledge, particularly in B2B technology companies, can be quite complex. Not only do Product Managers need to understand the overall market, but also market specifics that vary from geography to geography. They need to understand overall trends in the market, as well as technology and economic trends that could impact product performance. Then come the questions related to competitors — who are they, what are their strengths/weaknesses, and where are they heading? Finally, Product Managers need to understand their target customers in detail — what they do, what they find valuable, how they currently use your product (or one of your competitors), and why they would value yours.

All of these areas of knowledge constitute domain knowledge. The reality is, very few individuals can have a full understanding of all of this information. I believe there is a myth that the lone Product Manager can collect, analyse, understand and then react to all of this information. The reality is that technology companies should look at the Product Management function as opposed to the individual Product Manager, as the locus of this knowledge.

Clearly other teams in the company also have domain knowledge, but Product Management needs to collect it and put it all together to make a coherent picture out of it. To do that well, it can’t be the responsibility of a single individual. Companies should be thinking about Product Management teams for each of their products or product families.

Some companies seem to succeed in spite of themselves. You’ve all heard of (or maybe even worked for) at least one of these kinds of companies. They had an innovation that lead to a successful product, but couldn’t repeat that success. Why not? One of the principal reasons is lack of sufficient domain knowledge to make the leap to a second successful product.

Case Study

Remember Delrina Corp? The makers of WinFax? Back in the early 1990s, WinFax was the clear market leader for faxing on Windows operating systems. Everything in the company was focused on the Windows operating system.

I was a technical writer at the time, and was hired to join the “small but growing” Macintosh team at Delrina. The goal was, as I was told, to build out a whole product line of Macintosh products, with the first product being fax software. And who knew fax software better than Delrina, the people who invented it?

At the time, the core Macintosh development team consisted of three people: the lead (and sole) developer (Don), the QA engineer (Mike) and me (the tech writer).

During the development cycle of the first version of Delrina’s Macintosh fax software, a number of things happened that made me wonder if I’d made a good choice coming to Delrina.

Given that the three of us (Don, Mike and I) were virtually the only people in the entire company who had actually used a Macintosh, most people there only experienced the product through the documentation that I was writing (on a Windows PC using Ventura Publisher nonetheless — not my choice!).

On the Macintosh, the software worked by setting the fax-driver as the target for print jobs. This was done via the Chooser in the Macintosh environment.

At one cross-team meeting to review the development and documentation status, someone, I don’t recall who, asked:

“What are these Chooser and Finder things? Who named them that? Can we change them?”

I kid you not. I couldn’t make that up. Almost immediately Don looked at the person and stated, almost robotically:

“No we can’t change them or rename them. They are fundamental to the operation of the Macintosh.”

I gathered that this was not the first time he had uttered that line.

Later on, the issue of the product name came to light. At another cross-team meeting, it was announced that the naming committee had decided on a name for the product, and all software, documentation, marketing materials etc. should use the name. The name was….hold your breath: WinFax Mac.

Now, if you recall back to the early 1990s, it was the height of the Macintosh vs. Windows fight. Users in the Macintosh community were pretty vocal about their disdain for Windows.

Mike and I looked at each other and waited for Don to say something. Don made an attempt to hide his frustration and then tried to calmly explain why the prefix “Win” as in WinFax was not an acceptable name for a Macintosh product.

The Product Manager would have none of it. He explained the enormous brand equity “WinFax” had, and how strongly attached the name “WinFax” was to fax software and that the plan was to leverage it in this new foray in the Macintosh market. Mike also tried to explain the issues with using “Win” in the name of a Macintosh product and was also shut-down.

A couple of months later, at yet another cross-team meeting, the PM announced that feedback had been received from a large number of beta customers indicating their dislike of the product name, and thus a new name would be found without the prefix “Win” in it. Mike, Don and I looked at each other and rolled our eyes.

Once the project was complete, I decided to leave the company and find employment elsewhere. Even back then, early in my career, I could see the dark days ahead if I stayed at Delrina. I found work at a startup, but continued to track Delrina and their Macintosh product line. A few months later, I saw a review of the product in a computer magazine. The review was OK, but the documentation got a 4 out of 5! I still have a copy of that manual.

As it turned out, the fax product was Delrina’s first and last Macintosh product. Aside from Delrina’s lack of knowledge about the Macintosh computer and user community, they also didn’t understand the dynamics of the Macintosh fax market. Delrina had succeeded in the Windows market by being first to market with an innovative product, and then controlling the channels by signing OEM deals with virtually every PC fax hardware manufacturer. In short, virtually every PC faxmodem that shipped at the time came bundled with a copy of WinFax Lite.

The same strategy had already been executed by other Macintosh fax software manufacturers. So when Delrina entered the Macintosh market, it not only was a late entrant, but the channels were all tied up by competitors. Their strategy, leveraging their Windows dominance to enter the Macintosh market was completely useless. And why? Quite simply because they had no real domain knowledge or true understanding of the market they were entering. Decisions made in a vacuum always look pretty good at the time.

Disneyland knows Product Management - Worldpress Release

2008-04-27T11:27:00.000-07:00

A couple of years ago, when we were still living in the SF Bay Area, my wife and kids and I took a holiday down to Southern California. The objective was to hit the theme parks, see sights etc. Pretty typical stuff.

We first drove down to San Diego and went to SeaWorld and the San Diego Zoo. The zoo was pretty good and lived up to expectations. We liked the cable car ride over the zoo. It’s always nice to get up over the trees and see the world from another perspective.

The animal displays and pens were quite varied and certainly much better than the rather dated looking San Francisco zoo. But in the end it was still a zoo: pretty good but not really distinguished from any competing zoos.

The next day, we went to Sea World. Sea World is a bit of a strange place to be honest. From a positioning perspective, it’s part aquatic zoo, part educational institute and part theme park, but not exactly any of them. Schizophrenic is the term I would use.

SeaWorld started out as an attraction displaying marine mammals (sea lions, dolphins, killer whales etc.) performing various tricks. As the years went by, rides and other attractions were added to keep the people interested and occupied. There are only so many times people are willing to pay money to watch a killer whale perform a backflip!

From a product positioning perspective, this schizophrenia is troublesome.

During our day there, we attended the almost obligatory show featuring Shamu the killer whale. One thing that really annoyed me though, was that just before the show started, a brief video came on, featuring August A. Busch IV, welcoming everyone to the park and, in particular welcoming all the military families (San Diego is the home of the largest US Naval base on the West Coast) and acknowledging their sacrifice.

August A. Busch IV is the President and CEO, of Anheuser-Busch, Inc., the parent company of the SeaWorld and Busch Gardens theme parks.

Now, what was my problem? I’m on holidays with my family. I’m looking to remove myself from certain realities of the world and enjoy some time off. The last thing I want is to hear is a corporate/political pitch by some CEO who I’ve never heard of. Seriously…it completely removed any vacation context from my mind.

But then, given the schizophrenic nature of SeaWorld’s positioning, it should have been expected.

Next we went to Disneyland in Anaheim. We had bought three day passes for the family. Possibly overkill, but we wanted to take our time in the park.

So, why does Disneyland understand Product Management? Well comparing Disneyland with both the zoo and SeaWorld, there were a number of clear differences, starting from the moment we entered the grounds.

First of all, strange as it sounds, I can’t sing enough praises about the parking garage at Disneyland. Yes, you read that right. Disney has made even the mundane task of parking, ruthlessly efficient. Disney staff direct incoming vehicles into successive rows of empty parking spots. Contrast this to other parks, where, like in a shopping mall, you hunt up and down rows for an open spot.

After the parking lot, the tram ride into the theme park itself, helps put people into the right “Disney” frame of mind so that once they enter the park, they are ready to start enjoying the experience. And experience is the right word.

Once inside the park, there is no reference to the external world: no CEO videos, no newspapers, no CNN news feeds, nothing. The park staff are all in costume, down to the clean up crews, who do their jobs efficiently and unobtrusively.

Aside from the rides, the various characters that stroll around the park were interesting. Most, like Mickey, don’t talk. Some, like the green toy soldiers from Toy Story, don’t simply stroll, but enact certain behaviors that we’d expect of them. The soldiers, for example, move around the park in small groups, skulking from small building to small building.

My favorite character though, had to be the evil queen from Snow White. No fake smiles here. She kept a scowl on her face from the moment we encountered her. Yes, she took pictures with the kids, but not without throwing out a a few evil comments about princesses and dwarves. I think she’d give the CrankyPM a run for her money!

There were many other memorable things about the time we spent at Disneyland such as the evening fireworks and the truly unique Fantasmic show. But from a Product Management perspective, what I liked about their product was that it delivered on their promise, in an engaging, consistent, and satisfying way.

From installation (the parking lot), throughout the product usage lifecycle (3 days) and to the uninstall (back to the parking garage) we really enjoyed our time there. I’m not a big Disney booster (ask my wife), nor do I hold Disney stock, but the trip exceeded my expectations and despite the premium price over other parks, delivered real value. We won’t go back to SeaWorld or visit Busch Gardens, but will definitely go back to Disney theme parks.

I wrote a while back about a great experience with the premium-priced Dyson vacuum cleaner. In that post, I said:

when you build a superior product that turns a dowdy market-segment into one where customers rave about the product to their friends, you deserve success.

Now, I wouldn’t call theme parks “dowdy”, but I’ve never heard of too many people rave about SeaWorld. And I’ve been to other theme parks (Great America, Canada’s Wonderland) and neither provide the real experience that Disney does.

It’s more than simply positioning and consistency. It’s an end-to-end attention to detail, to really understand the needs of the target audience, and fulfill those needs as best as possible that makes a product successful.

And it’s not simply about having efficient parking lots and lack of external interruptions. Those are necessary in this case, but not sufficient.

It’s about defining a culture of customer focus throughout the organization, and ensuring that every customer interaction lives up to a standard that beats your competition. If you can do that, not only can you charge a premium price for your product, but you’ll develop incredible customer loyalty as well.

The technology industry could learn a lot from Disney.

Subscription Pricing vs. Enterprise Pricing

2008-04-27T11:22:00.000-07:00

Subscription Pricing vs. Enterprise Pricing

A question was recently posted in a number of Product Management discussion groups. It read (in part):

…I am working on adding a subscription based pricing model for our product. I have read articles that talk about the “rule of 17″ that suggest a monthly payment should be 1/17th of a perpetual license fee.

I have structured the models so that the “crossover” between the License fee model (including maintenance streams) and the subscription model was sometime in the first half of year 2. I have seen 3 year models as well.

What do you use or what have you seen? Have you offered both model for a time and if so what are the conflicts (if any) that arise?

It can sound very tempting to provide a subscription alternative to your own enterprise software, but you need to think beyond simply price, and think through the evaluation model, the sales model, the expense model (you’re now taking on the cost of hosting/operations), and how you go to market, convert leads etc. I’m assuming here that the subscription pricing is for a hosted or SaaS version of you current on premise software?

The approach to take is to start from first principles, and define the value proposition for the end user or customer.

There is a real tendency if you already have an on premise solution to:

Ensure you don’t cannibalize the revenue coming in from that solution
Use the pricing of the existing solution to determine the price of the SaaS version

If you go down either path, the subscription solution is likely to fail.

The first one will always put the existing product ahead of the subscription based product. This is what happened with Siebel on Demand. The existing business had to be protected from encroachment or cannibalization by the on demand business and it hampered the on demand business significantly. Your company will really need to shift it’s thinking to manage this well.

The second is tied to the first, but also ignores a really great opportunity you have to define a true value-based and scalable pricing model that could generate more revenue and have significantly higher customer retention than the current pricing model.

Spend some time with the target customers and understand the value proposition from subscription based pricing, and do some price sensitivity testing with them. This should really help you understand how the pricing can provide value. It may also show that there is no appetite for subscription based pricing, but I’m assuming that is not the situation in your case.

One of the interesting things about subscription pricing is that the money will often come out of OpEx budgets in companies whereas for traditional enterprise pricing, it will come from CapEx budgets. Now a dollar is a dollar, usually, but whose budget it comes out of make s a big difference in how people perceive price.

Additionally the pricing model has to take into account the true value delivered by the software. It is very easy to think of per seat per month or per user per month pricing. It certainly worked for SalesForce.com. But the beauty of subscription pricing is that you are not tied into that model or one model for that matter. But whatever you do, keep it simple! Enterprise pricing is ridiculously over complicated. Use the subscription pricing exercise to address that problem.

Figure out what the key units of value are from a customer perspective and use those for the pricing. There may be multiple models based on user scenario. While you don’t want to force existing customers to move to subscription pricing, you’ll have to figure out a transition pricing model to move them over (and possibly back) if needed.

Think of it this way. If one of your competitors came out with a competitive subscription based offering to your current product, would they simply take your pricing and apply the “rule of 17″? No, they’d figure out a compelling value proposition and pricing model and use that as a weapon against you. Get one up on your competition and do it before they do.

Product Information Management - Structured vs. Free-Form Approach

2008-04-27T10:41:00.000-07:00

Product Information Management - Structured vs. Free-Form Approach

Defining product structure (what is key prerequisite for any PDM system to work) that will satisfy needs of all users is still a "holy grail" of PLM. To make it a more attainable goal, compromises are required. They entail reduction of scope (often targeting a group of users sharing some relatively well defined product view - e.g. manufacturing release of the product), and standardization of the product definition within that scope (e.g. part numbering nomenclature, hierarchical trees, attributes, naming rules, etc.).

Even when limiting scope, to bring everyone to speed on how to use the information management solution may take long time. Stories about out of the box, fast and easy enterprise wide adoption are largely unfounded (most in fact relate to cases where a handful of early users test the system as a proof of concept for larger enterprise adoption). The limitation at play here often is less related to software. The culprit is nature of creative professionals to resent structure when it comes to sharing information. Yet, without sharing information in a fast and efficient manner, product development cannot be planned nor executed with quality and timeliness required in today's business environment. Let me elaborate on this before coming back to the main dilemma - when to use structured and when to use free-form approach to product information management.

Like many other information management solutions, systems used for product information management serve four main purposes: storing data, retrieving data, finding information, sharing information. For the purposes of storing and retrieving data, databases with relatively simple meta-data structures suffice and that is what most information systems found today in product development are designed for. In order to support finding and sharing of information, systems need to use structures with much more complex data models representing contexts within which the information is used. Visualization and 3D viewers coupled with structure trees are very popular for this. Yet, there is a myriad of contexts in product development not supported with any system. Since most information systems, in order to be successful, are designed with a narrower scope in mind, an inclusive data model that represents all contexts is not present in any single system. Consequently, structures useful in supporting data storage and retrieval for one group of users may confuse another group of users who simply want to see the same data in a context not considered in the system storing the data. For example, a product planner would love to know what would be a true cost of a new feature for which the price is yet to be determined, or sourcing manager may want to know how heavy are die cast parts of specific material (lets' say zinc alloy) currently being designed across all products...

Structures often get in the way of creative thinkers who over time develop alternative information searching and sharing solutions, following an informal (or free-form) approach. Let's examine our options here. I see three options, first one being alluded to above - a single data model supporting all contexts and all data required to generate information in all of the supported contexts. To support the fact that data is changing continuously, this option would require not only that all possible contexts are supported by the single data structure, but that all data be stored in a common repository and governed with a central meta-data authority. It is frightening to see how many enterprise architects out there still believe in this utopia. Second option, is to move data back and forth between various authoring databases to support multiple contexts represented in multiple systems. This option is popular when limited to just few systems and contexts, but would become unwieldy when extended to all recognized contexts. Change management would bring this option to its knees.

Here is a very interesting fact: vast majority of enterprise architects consider only these two options, quickly determining that second one for practical reasons will have to deteriorate into first, once the entire domain of structured product information is considered. While these two options are different in the architectural concept, essentially both options require product structure definition up-front.

Third option is to let the product structure evolve using morphing free-form definitions of the contexts within which the information is exchanged. In fact, that is what is going on in most of development organizations. As much as we would like to believe that our information systems bring discipline and order, we also have to be aware of the fact that they only cover a tip of the iceberg of the critical information and based on which decisions are made. As it follows, informal information sharing is a predominant approach to product development information management today. Usually, only final records of decisions make it to some structured data capture format where they are managed through subsequent iterations. Most contexts and problem solving steps that lead to these decisions never get tracked through any official data repositories. Social rules like authority and credibility govern the information sharing in the free-form approach.

So, what would the free-form approach look like. First, it is not based on product definition structure, but on organizational hierarchy and taxonomy of various skills and knowledge items. It lists all people who participate in the process and through series of associations with roles and key words describing their work products, it provides quick look ups of who should be in charge of what work product. Just like in this blog, each participant would maintain a log of tasks and/or posts that link to the underlying data directly related to their work products (3D designs, part tolerances, tests, material costs, ...). Here, even some fairly loose governance comes handy. For example, some users could automatically publish their task logs from internal tracking systems providing they have used them for their work. Others could choose from pre-specified log forms that are appropriate for the type of task they perform. Within these forms, links can be inserted to specific digital artifacts (data and documents) contained in their internal authoring systems. In each case, system architects would enable series of policies for retrieving and storing data directly into the systems through free-form entries wherever the logic of the process allows for it. Web services and XML document types come very handy for this purpose. Thus, exposing data from the authoring systems in contexts freely maintained by the users allows for fast finding and sharing of critical information.

Using structured and free-form approaches combined enables best of both worlds. Structure helps maintain and manipulate vast amount of data, while free-form contexts make that data available to all users based on their natural way of sharing it. Over time, the two can evolve, replacing the free-form contexts with mature structures (repeatable patterns) and allowing for new contexts to take shape as they are being discovered by the users. Governance in this approach is much more relax than in either centrally managed repository or system to system data exchange. Semantic reconciliation is simply left to people to execute through their internal preferences and shared points of view, while structured information does not need to cover complex contexts, becoming more and more reusable and reliable. Latest updates from several companies developing free-form solutions for product information management is more and more encouraging pointing to an accelerated adoption in the near future. Insight into early adopters shows very elegant solutions coupled with strong 3D and visualization capabilities, XML content re-purposing and web services for in-context data retrieval. Amazingly, the technology components required are very low cost, mostly available already in many companies, while best practice governance ideas are already forming as very portable and powerful policies for information sharing and search. My recommendation is to try free-form approach using common portal technology in limited scope (such as systems requirements management, simulation data management, test and validation) and observe how the organization reacts to it.

10 Steps to Business Innovation...

2008-04-27T10:25:00.000-07:00

1. Create a business/IT rotation program. Businesspeople often don’t know what to ask for from IT, and IT people often don’t know about business situations where IT could be applied. Move IT people into the business and vice versa and watch innovation bloom.

2. Move the focus from technology testing to simulation in a business context. Systems can work well and still fail because they don’t meet a business need. Test your systems in a business context—with real people, data and customers.

3. Build an innovation team. Innovation during the course of projects or daily business is accidental. Make it purposeful by devoting a small group to ongoing pilot projects and meetings with businesspeople.

4. Mesh IT development with product development. Product engineers are often segregated from IT, but with increasing levels of technology built into products, IT people could help speed the development process or even collaborate on new products.

5. Look outside the enterprise to partner with others on innovation. A swarm of small, global companies has moved in to take the place of big, internal corporate R&D departments.

6. Squeeze savings out of the infrastructure and dedicate the money to innovation. A program to constantly reduce fixed costs means there will be more money for innovation...without budget increases.

7. Use process improvement methodologies (CMM, ITIL and so on) to decrease innovation cycle time. Using CMM to standardize and improve software development processes means new projects can be completed more quickly.

8. Conduct interviews with all levels of the business. These discussions don’t have to be limited to specific projects. Interviewing businesspeople about what they do, what their problems are and what they’d like to do next is the first step toward innovation.

9. Create a joint IT and business capital spending plan. Many companies consider IT and business spending separately. It’s time to merge them. Linking the IT budget to plans to build a new factory could make it a better factory.

10. Design contractual requirements for innovation spending and planning with outside vendors. You devote a portion of your spending to innovation, so why not make business-specific innovation a part of your contracts with your vendors?

I wish there were 48 hours in a day...

2008-04-27T10:12:00.000-07:00

I wish there were 48 hours in a day.

Time management is a very important skill to master not only for our professional lives, but also for our personal well being. Effective use of time enables us to work more productively, lower stress levels, and have more time to do the things we need and enjoy doing. Here are ten tips that will help your time management.

Here are a few time management tips for you;

Organize your work area: File things where you'll find them, not where you think they belong according to a category. Think "where would I find this?"

Commit to a particular allotment of time for each project: Allowing yourself an hour a day for taking an action on a new project will keep your momentum going without being overwhelming or boring.

Do your most difficult work when you are in your peak performance state: If you're an early morning person, do that extra-effort-needed project first thing in the morning. If late evening hours are more your speed, save that high-energy project for that time.

Perform less demanding work at the time of day when you are most likely to be in a slump: If mid-afternoon is your body's sluggish time, save your mindless tasks and other less important to-do's for this time. The point is to get what you need done without wasting whatever time you have available to you at any given time.

Schedule your phone calls around your peak performance levels: You want to give your customers/clients your very best attention and this requires energy and enthusiasm.

Place your phone on voicemail mode at strategic times of the day: Voicemail is wonderful for those times when you're either feeling sluggish, want some quiet time, or just want to get a project done. You can access your messages later and return calls on a priority basis.

Let others in your home/office know when you don't want to be disturbed: Constant interruptions are annoying and distracting; they are also time-zappers. Letting people know when it's ok to interrupt and when it's not is crucial to time management.

Prioritize your day: Everything is not an earth-shattering emergency! Someone else's perception of a priority does not mean it is so to you. Discern what needs your attention immediately, what can be delegated, and what can be addressed later.

Delegate: Everything that needs to be done does not have to be done by you. Delegating to another person can save you a lot of time in mundane tasking.

Instead of a to-do list, create a goal for the day: Throw out the to-do list that never gets done, causes you stress and frustration, and makes you feel like a failure. Instead, set yourself a single goal for the day.

Follow these and you will never ever say, "I wish there were 48 hours in a day."

Time Management Matrix from First Things First, by Stephen R. Covey

Urgency is time related, importance is value related, but most people respond to urgency rather than importance. Whilst they can coincide, they are not the same and a key point with time management is to deal with important tasks before they become urgent, as it is easier to do the important tasks well when they are not urgent.

To use the Time Management Matrix effectively you need to decide what sits where and focus on the important tasks rather than urgent ones. Although, in the short-term, you must do the urgent and important tasks first, for more effective time management in the longer-term, it is better to focus on quadrant 2 – the tasks which are important, but not yet urgent.

The core skill in time management is deciding what tasks lie in each square and having the discipline to do them in the right order.

People will often do tasks in quadrants 3 and 4 rather than sector 2, as displacement activities. A great example of this is office tidying, or answering emails, when you have something important to be working on. The key question to ask is, ‘if it is not important why are you doing it?’ If it is not important then these tasks can either be dumped, or delegated.

Asking your researchers the following questions, with reference to this model, may help move them forward, by giving them greater clarity on what is really important and urgent in their work

What are the demands on your time? (categorise them into the table above)
What will you need to do differently to manage your time more effectively?

Advertise Yourself...

2008-04-27T10:02:00.000-07:00

Advertise Yourself

Why do you need to brand yourself?

When people want to associate with you professionally, they need to be comfortable knowing who they are dealing with. This could be for a job, a contract, an assignment or a partnership or investment in a venture. The greater your personal brand equity, the bigger break you could get.

E-brand yourself

Branding yourself does not mean you have to put up billboards of yourself around town. The virtual world is your magic lamp; do the following and see how you stand taller among your peers.
A personal website
It could be an extension of your blog or a separate one. Let it be like your online CV covering academics, career path, testimonials, photographs, achievements, skills, published works, links to your blog and work-related sites and other relevant information. Make sure your website and blogs are well designed -- select neat templates and inviting colors. Don't be flashy for the sake of it.
Set up a public profile
The starting point. Go to a professional networking site, and create an account. Fill out everything about yourself in detail as required, including your special achievements and skills. Get people to post recommendations on your profile. Make sure you also build a quality network of contacts -- this will show who you know and who knows you. At a glance others will know all about you professionally.
A personal blog
Get yourself one; these are free and can be set up in minutes on sites like Rediff, Blogger and Wordpress. You can also get a domain with a custom name, even your own, which is a good idea. Talk about one subject you feel strongly about -- it could be about your professional expertise, public interest issues, travel, a hobby or anything else. Set up multiple blogs if you have the capacity to maintain the same. When deciding a subject area, ask yourself this question: Will anyone care to read about what I am writing? Go ahead only if the answer is in the affirmative. Stay clear of personal ramblings -- what you write will reflect on the kind of person you are and how you think.
Write for publications
Look for any available opportunities to write for websites, newspapers and magazines -- people will notice you and this will add to your profile. Media outlets are always open to accepting columns from experts and knowledgeable professionals.
Show yourself to be an expert
There are many online forums where you can participate in Question and Answer sessions. Join the ones where business subjects are discussed; there is none as powerful as the one on LinkedIn.com. When you share your knowledge, people start recognising you for your expertise in your area of work -- and you don't know who may want to connect with you and send an opportunity your way. Be on social networking sites also. Show yourself to be multi-dimensional. These sites, unlike professional networking ones, are more about your personal side like your hobbies, holidays, family and friendships.

Network, network, and network

Develop relationships with as many people as you can, with diverse backgrounds and not just relevant to your own industry. Everyone has a contribution to make. And the internet, especially through social networking sites, allows you to do so without moving away from your desk.By doing this you would not only buildup your relationship but also learn and enhance various skills to polish yourself.

Delegate tactical responsibilities

2008-04-15T11:53:00.000-07:00

If you want to be a bad product manager, do everything yourself. You’re the product manager, after all, so you should be the final authority on everything related to the product. You should be the one answering questions from salespeople, drafting press releases for marketing, defining all of the processes for suppliers, and poring over every detail with engineering. Sure it takes a lot of your time, but that’s what a product manager should be spending time on. What other more important things are there to do?

If you want to be a good product manager, delegate tactical activities to allow you to spend time on the strategic aspects of the job. Effective product managers pass on product knowledge and responsibility for tactical decision-making as much as possible to others on the product development team. By leveraging the rest of the team, the product manager can focus on the strategic role of product management.

It is difficult for many product managers — especially new product managers — to effectively balance the strategic and tactical priorities of product management. With so many competing priorities, the minutia and day-to-day tends to take over. To extend a common metaphor, it’s not just that product managers sometimes focus on the trees instead of the forest — they go so far as to end up focusing on a specific piece of bark.

While it is easy to say that product managers should be more strategic and less tactical, actually accomplishing that is a significant challenge. Pragmatic Marketing recently released the free ebook “The Strategic Role of Product Management,” by Steve Johnson, which describes why product management is a strategic role and why product managers need to think and act strategically. Buried in the “Final thoughts” section is this beautiful nugget of wisdom (emphasis added):

Product management is a strategic role. Yet as experts in the product and the market, product managers are often pulled into tactical activities. Developers want product managers to prioritize requirements; marketing people want product managers to write copy; sales people want product managers for demo after demo. Product managers are so busy supporting the other departments they have no time remaining for actual product management. But just because the product manager is an expert in the product doesn’t mean no one else needs product expertise.

Product managers should take heed of this last sentence. Think about all of the tactical activities in which you engage — documenting details, answering questions, describing functionality, responding to feedback, tracking down responses, and the like. How much of your time is taken up by these activities? Why are you engaged in them? Is it because

you are the only person in the company who knows how?
everyone else is busy and you are the only one who has free time?
they are so important that they must be done by you and only you?

The answer to these questions is probably an emphatic NO in most cases. The real reason that product managers are engaged in these activities is because they have done them in the past, so others assume they will do them in the future. Every time a product manager writes copy for marketing, or conducts a demo for sales, or investigates some technical issues for development, the product manager creates the expectation that he or she will do that in the future. Obviously, there are some occasions where this may be appropriate, However, the vast majority of the time, the product manager can and should be giving the necessary direction, context, and guidance to allow other people to accomplish these tasks themselves.

Most product managers do not have staff reporting to them, so it is not necessarily as easy as delegating tasks to a direct report. Instead, product managers need to leverage others and teach them to be self-sufficient. This is not to say that product managers should ignore requests or haphazardly push off their responsibilities, of course. Instead, product managers should look to make those around them more effective by providing them with the tools, information, or resources they need.

Every time you as a product manager are presented with a task, ask yourself these questions:

Is this helping to advance the product strategy?
Does this support one of the high-level goals for my product?
Is there anyone else within the company besides me who can accomplish this task (e.g. answer this question, investigate this problem)?
Is this something that has come up before or is likely to come up again?
Is this a valuable use of my time?

It’s never easy saying “no,” though it may be easier to look at it this way — every time a product manager says “yes” to something that is tactical and routine, they are saying “no” to something that is forward-looking and strategic. Which would you feel more comfortable telling your boss — or the CEO — that you said “no” to?

So what do you do with the tactical activities — those requests for copy writing, operational meetings, responses to customers, and discussions of detailed product minutia? Ask yourself — and others — whether they are really necessary, or at least whether it is really necessary for you to be included. Going back to the three questions posed earlier, look at why you are engaged in tactical activities:

If you are the only one who knows some vital piece of information, figure out some way to rectify that. Document it, communicate it, teach it to others, pick someone to transfer knowledge — find some way to make sure that someone else has the information. Beyond just providing better use of your time, this can be vital for business continuity and succession planning.
If everyone else is claiming to be busy and is offloading responsibilities, the same can be doubly true for a product manager. Help create ways for people to answer questions or streamline tasks on their own, rather than passing on their additional work for you.
If there really are activities that appear to be vital enough to be performed by you and only by you, analyze those activities closely. Some may seem critical at first glance, though upon review you may notice that they are not as important as originally thought. Also, other people may be turning to you because they think you want to be involved, or because they think you would be offended if you were not consulted. Just because someone else thinks a task is crucial enough that it must only be done by you does not mean that you have to agree with them.

Lastly, if you are involved in these activities only because you have always been — well, then make it a resolution to stop today! The more product managers can think about their role as being strategic and market-focused, the more they can add value to the organization and to customers. Effective product managers help create more product expertise within the company. This gives the product manager as much time as possible to focus on the reason the company created the position — to add value by creating and improving market-focused products.

Do not be afraid to remove features

2008-04-15T11:46:00.001-07:00

If you want to be a bad product manager, don’t ever remove features. Why would you take something out of your product? More features just make the product better, so taking away features would obviously make the product worse. Sure, not everyone will use every feature, but that’s why you have so many of them. What if you take away something that even just a small portion of your customers use and you alienate them? Customers always ask for more features — not less — so in the end, the product with the most features win.

If you want to be a good product manager, be smart about removing features. Having a lot of features will not make your product great. Great products come from having the right features to solve customer problems, and having those features designed in the right way.

Removing features can and should be done to many products. Good product managers confront this difficult aspect of the job, even though it can be challenging and uncomfortable. Similarly, good product managers do not take this responsibility lightly and only remove features once they understand the implications of any changes to the product and the customer.

The first step to removing features is to not add unnecessary features in the first place. Too often, irrelevant features are added for various reasons — knee jerk response to a customer complaint, an engineer’s pet idea, a lack of understanding of customer needs. Then, when features need to be removed for some reason — technical challenges, support cost, instability — the amount of hassle that a product manager has to endure to minimize impact to customers is much greater than the value than the feature ever provided.

As Marty Cagan of Silicon Valley Product group writes in Great Products by Design:

The job of the product manager is to identify the minimal possible product that meets the objectives and provides the desired user experience — minimizing time to market, user and implementation complexity.

In a “minimal possible product,” there are no unnecessary features. Every aspect of the product is absolutely essential to meeting the relevant goals.

Unfortunately, product managers often inherit products which were not designed in this way, and there are nearly always features that are not necessary to meeting the business and user objectives.

There are two steps to removing features — identifying which features to remove, and explaining to your customers why you are removing these features.

1. Identifying which features to remove should not be a haphazard progress. Features to remove are those which

are costly to support
present a liability to the product
detract from other value-adding features
do not fit with the product strategy
are not used by customers

Once you have identified a feature that falls into this category, identify why the feature was added in the first place. Was it designed to attract to a specific type of customer? Was it relevant when launched yet inappropriate now given technical progress in the years since? Regardless of the validity of the reasoning, first seek to understand it.

Then, see if that reasoning is still valid. It may have made sense given the original product strategy, though now it contradicts the current strategy. Maybe the feature was unique and differentiating at the time and is commonplace and irrelevant now. Perhaps the goal of adding a certain feature was to capture a new type of customer, and that strategy that never succeeded.

Ultimately, product managers should seek to identify any feature whose removal would have no impact on revenue. Yes, customers may complain a bit, though that is likely happening irrespective of whether the feature exists or not. If features can be removed without any measurable loss in customer satisfaction or usage — both of which ultimately lead to revenue — what is the benefit to keeping them? Similarly, if adding a new feature will have no measurable increase in customer satisfaction, usage, or revenue, what is the benefit of adding it? If more product managers kept this in mind as they considered product improvements, they would not get themselves into the situation of having to remove features.

2. Explaining to your customers why you are removing these features is relatively straightforward once you have done the analysis explained above. This is not to imply that you have to deceive your market and put a positive “spin” on the change. You should be honest and straightforward with your customers when describing the reasoning for the change. This should be presented in the terms of the benefits to customers. For example, by removing some icons from the main menu bar, it will make the menu bar easier for new users to learn and quicker for experienced users to use; or, resources will be put towards new features that your customers have been requesting rather than supporting features that are costly to maintain and seldom used.

Make the transition as smooth as possible for customers. Give them plenty of advance notice and make sure to communicate in several forms — for example, through your sales force, via email, postal mail, webinars, etc.

For customers who did rely on the feature which is being removed, you can also suggest alternative options where possible, even when those alternatives are competing products. If the feature really is that unimportant to your users, you will not have droves of customers leaving because of a small change in your product. Customers will appreciate your candor and assistance in minimizing the impacts of the change.

Whenever possible, implement enhancements to your product at the same time that you remove features. Not only does this provide an improved product for your customers, it is a much easier message to communicate. Instead of defending your subtractions, you are extolling your improvements and explaining how those subtractions were a necessary part of the enhancements. 37signals describes this as “every time you add something you take something away,” and the comments and discussion around their blog post show the challenge and confusion around this topic.

Good product managers need to have a clear product strategy and ensure their product remains focused. This can be done by being very regimented in their product development and only adding new features that enhance the product’s value. However, when there are features present whose cost outweighs their value, a product manager must make the difficult decision to remove them to ensure focus on the product’s vision.

Secrets of Successful Project Management

2008-04-15T11:26:00.000-07:00

Managing software projects is difficult under the best circumstances. Unfortunately, many new project managers receive virtually no job training. Here are 20 tips for success.

1. Define project success criteria.

At the beginning of the project, make sure the stakeholders share a common understanding of how they will determine whether this project is successful. Too often, meeting a predetermined schedule is the only apparent success factor, but there are certainly others. Some examples are increasing market share, reaching a specified sales volume or revenue, achieving specific customer satisfaction measures, retiring a high-maintenance legacy system, and achieving a particular transaction processing volume and correctness.

2. Identify project drivers, constraints, and degrees of freedom.

Every project needs to balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver aligned with project success, or a degree of freedom that you can adjust within some stated bounds to succeed.

3. Define product release criteria.

Early in the project, decide what criteria will determine whether or not the product is ready for release. You might base release criteria on the number of high-priority defects still open, performance measurements, specific functionality being fully operational, or other indicators that the project has met its goals. Whatever criteria you choose should be realistic, measurable, documented, and aligned with what “quality” means to your customers.

4. Negotiate commitments.

Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers and managers about what is realistically achievable. Any data you have from previous projects will help you make persuasive arguments, although there is no real defense against unreasonable people.

5. Write a plan.

Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is actually doing the planning—thinking, negotiating, balancing, talking, asking, and listening. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project.

6. Decompose tasks to inch-pebble granularity.

Inch-pebbles are miniature milestones. Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking.

7. Develop planning work sheets for common large tasks.

If your team frequently undertakes certain common tasks, such as implementing a new object class, develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he or she must tackle.

8. Plan to do rework after a quality control activity.

Almost all quality control activities, such as testing and technical reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. If you don’t actually have to do any rework, great; you’re ahead of schedule on that task. But don’t count on it.

9. Plan time for process improvement.

Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement. Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100% of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives.

10. Manage project risks.

If you don’t identify and control risks, they will control you. Spend some time during project planning to brainstorm possible risk factors, evaluate their potential threat, and decide how you can mitigate or prevent them.

11. Estimate based on effort, not calendar time.

People generally provide estimates in units of calendar time, but I prefer to estimate the amount of effort (in labor hours) associated with a task, then translate the effort into a calendar-time estimate. This translation is based on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency fix requests I might get, meetings, and all the other places into which time disappears.

12. Don’t schedule people for more than 80% of their time.

Tracking the average weekly hours that your team members actually spend working on their project assignments is a real eye-opener. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Don’t assume that just because someone spends 10 hours per week on a particular activity, he or she can do four of them at once; you’ll be lucky if he or she can handle three.

13. Build training time into the schedule.

Determine how much time your team members typically spend on training activities annually, and subtract that from the time available for them to be assigned to project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.

14. Record estimates and how you derived them.

When you prepare estimates for your work, write them down and document how you arrived at each one. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary, and it will help you improve your estimation process.

15. Record estimates and use estimation tools.

Many commercial tools are available to help you estimate entire projects. With their large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you stay out of the “impossible region,” combinations of product size, team size, and schedule where no known project has been successful. A good tool to try is Estimate Pro from the Software Productivity Centre (www.spc.ca).

16. Respect the learning curve.

If you’re trying new processes, tools, or technologies for the first time on this project, recognize that you will pay a price in terms of a short-term productivity loss. Don’t expect to get the fabulous benefits of new software engineering approaches on the first try, and build extra time into the schedule to account for the inevitable learning curve.

17. Plan contingency buffers.

Things never go precisely as you plan on a project, so your budget and schedule should include some contingency buffers at the end of major phases to accommodate the unforeseen. Unfortunately, your manager or customer may view these buffers as padding, rather than the sensible acknowledgement of reality that they are. Point to unpleasant surprises on previous projects as a rationale for your foresight.

18. Record actuals and estimates.

If you don’t record the actual effort or time spent on each task and compare them to your estimates, you’ll never improve your estimating approach. Your estimates will forever remain guesses.

19. Count tasks as complete only when they’re 100% complete.

One benefit of using inch-pebbles for task planning is that you can classify each small task as either done or not done, which is more realistic than trying to estimate what percent of a large task is complete at any time. Don’t let people “round up” their task completion status; use explicit criteria to tell whether a step truly is completed.

20. Track project status openly and honestly.

Create a climate in which team members feel safe reporting project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that sometimes arises from fear of reporting bad news. Use project status information to take corrective actions when necessary and to celebrate when you can.

These tips won’t guarantee success, but they will help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in a crazy world.