20 Basic ITIL Metrics

ITIL breaks major IT functions down into nice bite sized processes — ripe to be measured with metrics. Here are 20 of our favorite metrics for ITIL processes:

Incident and Problem Management

1. Percentage of Incidents Resolved by First Level Support 
Support costs can be dramatically reduced when first line support resolves basic issues such as user training, password problems, menu navigation issues etc... The target for this metric is often set above 80%.

2. Mean Time to Repair (MTTR) 
Average time to fix an incident. Often the most closely watched ITIL related metric. It is not unusual for MTTR reporting to go to CxO level executives.

3. Percentage of Incidents Categorized as Problems 
The percentage of incidents that are deemed to be the result of problems.

4. Problems Outstanding 
The total number of problems that are unresolved.

Service Desk

5. Missed Calls
The number of times someone called the help desk, were put on hold and eventually hung up. May include the number of times someone called when the help desk was closed. Impacts customer service and core metrics such as MTTR.

6. Customer Satisfaction 
Usually captured in a survey. Try not to go overboard: asking for feedback in an inappropriate way can irritate customers.

7. Staff Turnover 
Service Desk jobs can be stressful — retaining experienced staff is critical to optimizing core ITIL metrics.

Change Management

8.Number of Successful Changes (change throughput) 
Change throughput is a good measure of change management productivity.

9. Percentage of Failed Changes 
A change management quality metric — can impact customer satisfaction and availability management.

10. Change Backlog 
Total number of changes waiting in the queue.

11. Mean RFC (Request for Change) Turnaround Time (MRTT) 
The average time it takes to implement a change after it is requested.

Release Management

12. Percentage of Failed Releases 
The percentage of releases that fail — a key Release Management quality metric.

13. Total Release Downtime (TRD) 
Total downtime due to release activity.

Availability Management

14. Total Downtime
Total downtimes broken down by service.

15. Total SLA Violations 
Number of times that the availability terms laid out in SLAs were violated.

IT Financial Management

16. Percentage of Projects Within Budget 
The percentage of projects that did not go over/under their prescribed budget.

17. Total Actual vs Budgeted Costs 
Total actual project costs as a percentage of budgeted project costs. Calculated for an entire project portfolio. A number over 100% indicates over spending.

Service Level Management

18. Total SLA violations 
The number of SLA violations in a given period.

19. Mean Time to Resolve SLA Violations 
The average time it takes to restore SLA compliance when a violation occurs.

Configuration Management

20. CI Data Quality
Percentage of CIs with data issues. Can be determined by sampling methods.

Why Project Managers need People Skills

Recently, I was having a discussion on why project managers need to excel in people skills. On the surface, most project managers do not have people management function and tend to discount people skills.

Project managers are often individual contributors who have no people management functions. Moreover, project managers are often overloaded with overseeing several projects, which places heavy load on their time. I have seen few project managers handling 6-8 projects simultaneously.

As a result, project managers tend to discount people skills and rely on technical skills alone. This may work in certain conditions - but in the long run, to be a really successful project manager one need good people skills.

Benefits of having good people skills:

1. We live in a global world where projects are being executed by a globally dispersed teams. In such an environment, it is rare and a luxury to meet people face-to-face and build rapport with various stake holders. Many project managers may never see some of the stakeholders and customers face-to-face.
2. In today's hyper competitive world, there is a constant pressure to complete projects faster than before. Reduction of project cycle times has become crucial for success.
3. Projects and programs are becoming more complex. In software world, new projects are being launched on unproven technologies. So for a project manager, this becomes very difficult to identify project risks. The only way to correctly identify project risks is to connect with people working on that project and then get a first hand information of all the risks.
4. Engineers often multitask. Today it is common for engineers to be working on more than one project. So unless project managers can build a good personal rapport with the team, the project can suffer with unexpected delays and defects.
5. Project Managers work in a matrix organization, often reporting to several stake holders. Having good people skills helps in managing several stakeholders. Having good people skills will make it easier to interact with various stakeholders and get a more positive outcomes.
6. Many organization do not have clearly demarcated management roles. Engineering execution managers often step into project manager's space and vice-versa. In such cases having good people skills help in smooth interactions and reduce friction. 

Product Management - Design for Sustainability

Design for sustainability (D4S) is fast becoming a a baseline standard for new product design in several sectors. Construction industry has taken a lead in terms of defining standards for sustainable buildings and followed it up with certification programs. LEED Certification for buildings has become mainstream in the US and similar certification program from IGBC is taking roots in India.

2015 United Nations Climate Change Conference begins in Paris on November 30th 2015.  As world leaders talk and negotiate deals on global climate issues, we as product managers can do few things on developing sustainable products.

A truly sustainable product is one that:

• Uses the waste of other processes as its input, and minimizes or eliminates the use of virgin materials extracted from the earth
  
• Creates output that can be used by other processes or returned to a natural state, and eliminates waste that can't be used or returned to a natural state
  
• Uses the least amount of energy to manufacture the product and to achieve the desired outcome.

Today, Sustainability can no longer be just a buzz word. Today, Sustainability has to be the core in companies at a variety of levels starting at the highest levels.

1. Strategy. 
Some companies decide what to make or do based on sustainable business
ideals. Godrej Group has made environmental sustainability as a key part of its
business strategy. Godrej Properties - the real estate arm of Godrej has been a leader in Green buildings and is a sponsor of IGBC Green Building Certification program.

2. Supply chain. 
Retail companies such as Walmart requires its suppliers to disclose and evaluate full environmental impact of their products. Companies are now paying deep attention to industrial ecology, which analyzes all the material and energy required to create the product. This often extends beyond the domain of a single business and right to the basic sources of raw materials. For example, retailers such as Tata Chemicals is promoting Organic food products under the brand Tata Shakti, Starbucks is promoting Fair Trade Coffee etc.

3. Operations 
Decisions about how to make and move products increasingly reflect environmental impacts. Companies are now looking at all levels of operations to lower energy usage and now have created Environmental Management Systems (EMS), which have operationalized the tracking, documentation, and reporting of environmental impacts by day to day operations. The businesses can no longer hide from legal implications of negative environmental impacts. In case of several industries, there are several legal or regulatory requirement to adhere to minimum environmental practices.

4. Product development & design
Companies have incorporated sustainability into their new product development process in ways ranging from specifically creating "green" products. Sustainable products are those products that provide environmental, social and economic benefits while protecting public health and environment over their whole life cycle, from the extraction of raw materials until the final disposal.

Many faces of sustainable product design

Now that I have given a bit of background on sustainability, let's talk about sustainable product design.

Sustainable design is the term we've chosen to represent the intelligent application of the
principles of sustainability to the realm of engineering and design of products.

The term "sustainable design" is just one holistic term used to describe the use of sustainability principles in the design and development of products. This includes sustainable engineering, environmentally sustainable design, eco-design, and green design.

When products are to be designed for sustainability, there are several factors that needs to considered during the product design stage:

1. Design for Environment
2. Design for Disassembly & Recycling
3. Design for Energy Efficiency
4. Design for Health & wellness
5. Green Marketing

Design for Environment 

The Objective here is to minimize pollution and thus reduce human and environmental risks that the product entails. It means designing products that should be safe (both during operation of the product and after disposal) for human health and the environment. It could mean use of green chemistry - products that leave no or minimum residues or chemical that are biodegradable etc.

This starts with identifying industrial & institutional products that are deemed to be safer for human health and the environment through an evaluation, define best practices and identify safer chemical alternatives.  

At this stage of product design, It also involves identifying use of sustainable raw material inputs for the product and also use of recycled raw materials.

Design for Disassembly

This design aspect is essentially to address the end-of-life phase of product by designing the product that is easy to disassemble and enable the easy recovery of parts, components, and materials from products for recycling at the end of their life.
Recycling and reuse are a good way to create a sustainable world, but it requires products that can be disassembled cleanly and effectively. Design at this stage is primarily focused on end-of-life considerations as one means of encouraging more environmentally conscious design and greater resource conservation.

Design for Energy Efficiency

Environmental impact of product over the lifespan of the product has to be considered. Products must be designed to minimize the environmental impact. Product must be designed to use minimize energy usage during its lifetime. Every version of product must review the energy usage and develop new technologies to reduce energy usage.

Design for Health & Wellness

All products have to be used by people and during its life span, the product must not emit any hazardous outputs that impact health & wellness of the operators. This includes chemical vapors, heat, light, noise or electromagnetic radiation which adversely impact the health & wellness of the operators. For example, design newer cell phones that emit lesser radiation.

Products that use volatile chemicals in form of adhesives or paints must be designed to use chemicals that emit less or does not cause any harm.

Green Marketing

Green Products can have a powerful advantage. Companies find that green products and  promoting the environmental responsibility/benefits of their products has a powerful marketing angle. Touting the "green" aspects of existing products, processes, or systems has immensely  benefit product marketing.

From product design perspective, it helps product designers and product marketing to work together to know what benefits of their sustainable design and engineering efforts can be claimed publicly.

Green Product Leadership  

Developing Green Products often requires taking a leadership position for the extended product supply chain. This requires voluntary partnerships among manufacturers, retailers, government, and non-government organizations to set up effective green supply chain systems and practices. For example, in case of cell phone batteries - it will require working with raw material suppliers and also product recyclers and environmental agencies.

Taking product leadership means encouraging more environmentally conscious design and greater resource conservation. Working with various public and private sector stakeholders, to promote 'greener' design, setting up greener product standards, and establishing greener purchasing practices.

From Green Product Leadership perspective, there are many ways to create environmentally sustainable business ecosystems. Sustainable design is just one aspect. Designing products for a broader purpose by matching user needs with right products that last for the lifetime of the customer needs, will eventually change customer behavior and sustainable designs can influence user behavior for a more sustainable use cases.

While designing green products, one must think in terms of whole systems, the ecosystem context, product service and the supply chain. Only then the product will be really "green" and help create a sustainable world.

Closing Thoughts 

We are now at the start of establishing an ecological civilization. The old thinking of industrial civilization that sees the relationship between humans and nature as opponents, and uses technology to tame the wild nature - must go away.

Sustainable products and Green engineering looks at the relationship between humans and nature as a harmonious symbiotic relationship.  

Minimizing Risks in New Product Development

All too often, we hear about risks and failures with new product development. Developing new products is a complex, expensive process and has unpredictable outcomes. In other words, new product development is fraught with risk.

Every week, thousands of new mobile apps are being developed. But a handful of them make any money. If you are developing a new product - even with a disciplined business plan, a well managed project management and all other business processes in place, new products can still have unpredictable results. Even successful/innovative companies have seen product failures.

It is almost impossible to eliminate the risks associated with new products, there are few things one must do to minimize the risks. It begins with aligning the business goals with a proven technology possibilities to produce successful & innovative products.

1. Develop a pragmatic business goals.  

Apple sold 26 million pieces of iPhone 6.  So, if you are a competitor to iPhone, and define your business plan is to sell 20 Million phones a quarter, then the plan is set up for failure. Instead develop a pragmatic plan which takes into account of various factors: Marketing & Sales channels, supply chain, etc.

The plan must be something achievable, realistic, and consider the inputs from other parts of organization.

Start by clearly defining and articulating the business plan and validate it through objective analysis before embarking on significant new product development activities. The business objectives should be unemotional, objective and quantifiable. This helps us in a big way in decision making during the project and not waste time.

2. Don't Rely Exclusively on the Voice of the Customer.

Contrary to existing conventional wisdom, relying exclusively on the voice of the customer will often steer you on wrong direction. Customer often adds his wish list into the requirements - just to see if it can be done. Customers may not always know what they really want, and they rarely know what is technically possible.

Instead of listening solely to what customers are saying, also look at what customers are willing to pay for. Identify what is the bare minimum features that customers will pay for and then use your instincts, intuition & market knowledge to identify all the required features.

This makes it possible to reliably develop the new products in cost-effective way and that can be sold to customers.

3. Bring proven technologies from other companies. 

Most new products needs new technologies. Current players may not have developed the product idea you have - because the current technology/platform may not be capable. So the first step is to evaluate new technologies and adapt proven technologies - mainly from other companies. Typically, startups often test new technologies and it makes sense to copy it fast  if the technology is already proven.

Large technology companies acquire startups for their proven technology. For example, Cisco acquired Meraki & EMC acquired iWave etc.

Applying proven technology from other company reduces the risks while enabling rapid product development.

4. New Product Development requires disciplined project management.

New product development requires innovation. And innovation typically has a reputation for uncertainty and unpredictability. By approaching innovation with a pragmatic and disciplined project management process, it takes away the risks. If the innovative project does not deliver expected results or fails to meet the milestones, then having a disciplined approach helps to identify risks ahead of time and take corrective measures - even if it implies canceling the project.

A disciplined project management implies:

• Knowing the key milestones and final objectives
• Project plan calls for measuring the pace of innovation
• Align innovation with new product development plans
• Keep the project on course when distractions occur.

The discipline to spend time up front helps reduce the risks associated with the creative and technological sides of innovation. This will ensure that what goes into the project is truly meaningful and will yield the desired business results at the end, when the new product arrives on the store shelves.

Project management is an upfront investment to avoid "garbage in, garbage out". Defining all the inputs and expected outputs in the project will avoid wasting resources and minimizes risks.

5. Create an agile development team 

New product development requires an ability to change if the market needs change. Ability to read the market needs quickly and adapt to the changes is critical for success. Agility starts at business leadership level and must spread across the organization, including marketing and technical teams.

One must constantly be monitor what's going on in the world, what are the trends in technology and marketing? And ask "How does this impact our product?" "How should we adapt to succeed in this?"

New product development requires agility from everyone involved.  

Product Leadership - Building Successful & Innovative Products

One can learn good management theory and principles in MBA colleges. One can learn creativity and design in design institutes. But no one teaches how to create successful products!

Creating successful new products requires a right marriage of right brain thinking:  creativity/design, and left brain thinking: Process, science/maths, rational management. Apple Inc. is a perfect example of left brain right brain thinking - Jonathan Ive the designer and Tim Cook, the operations manager. Steve Jobs the business leader.

Every company that develops new products needs product leaders managers who can get the right balance between creative people and managers to create successful products.

Product leader has to bring in few tricks: "Design thinking" and "Lean Development"  techniques to rapidly experiment with solutions.

The secret for success in new product development is to understand that developing new products is not much about product development! Instead, it is all about creating customers!

Creating customers is all about understanding customer needs, desires, & problems, and solving it profitably. If the number of customers are large enough, then you have created a successful product.

Since there is a very high level of uncertainty in creating new customers, one needs to be agile & lean when it comes to trying out new designs - i.e, ability to move/change/adopt quickly. Since things are at flux and needs are constantly changing one has to be lean - i.e., use minimal resources for experimentation.

Startups generally are good at new product development - mainly because they are not focusing on sustaining customers. They are creating new customers. They have few resources & are forced to be lean and they are agile. Enabled with rapid decision making leadership, who is not afraid to experiment or fail, Startups are constantly figuring out how to create a customer.

I always say "Without a customer, you don't have a product. You only have a prototype!"

I have worked in startups and have seem several other start ups and established companies follow a similar process towards new product development. Often

Step 1: Develop an Insight: 
Identify what the market needs or desires. Start with talking to customers, question customers current levels of comfort & needs. Observe customers and learn. Network with similar minded people. Also be ready for surprises. Lastly experiment - to get deeper insights about problems that is worth solving.

Step 2: Define the Problem: 
To develop a successful product, one needs to know what is the real problem that needs to be solved. Competition could also have the same insight - but had failed, because they did not solve the right problem.  Discover the customers' need or problem first, and then make sure you are going after a problem worth solving.

Step 3: Solution: 
Develop a prototype first. Check if the prototype meets the minimum requirement in terms of solving the customer problem. Practice agile & lean principles to rapidly develop prototypes - instead of developing full scale products. If needed, develop multiple prototypes, each to solve many aspects of customer problem. Iterate until you develop an awesome product - the one that delights customers.

Step 4: Develop Business Model: 
The finally solution must be priced to market. Carefully examine the entire cost structures, validate go-to-market strategy. If the need be, one has be creative in pricing the product. A differentiated pricing strategy that makes it easier for customer to acquire the product.

Closing Thoughts

Product Leaders must push the design and management teams to go beyond the obvious. Force the team to Think differently or experiment. Accept failures during prototype stage - and fail fast. Once a failure is identified, pull out the product and iterate until the product succeeds.

Leaders must embrace uncertainty in the product development, Challenge the problem statement until every stakeholder is convinced of the problem, Set a high pace for development, and be bold in experimentation.

Role of Customer in New Product Development

In my previous article: First Steps in Developing New Software products,  I had made a reference to a stage of defining product features. There are many ways to identify product features and functionality. One of the ways is to involve a potential customer in the early stage of new product development.

The key advantage of involving customers at an early stage is to minimize the risk of developing features & functions - which are of no value to customers. It also helps in taking active customer feedback at the time of product definition and that helps in a BIG way to minimize risks of product failure.

Improve the Odds By working with the Customer

I had good fortune to work at both a large technology company in Santa Clara, and also at a startup and also in a very large technology company. All through my experience, I have been involved in product development, from both technology side and business side. Based on my experience, I seen the value of customer involvement at an early stage of product definition.

Normally, all new product development goes through cycles of  "IDEA" -> "Build Product" -> "Measure Customer Response" -> "Learn from Customer Data" -> "New Idea".

Involving customers at an early stage of product development has several benefits.

1. It will help avoid mistakes and it allows the developer to explore and iterate during the cheapest phase of development - before any code is written, and when the product is still in the mockup stage. Customers can give valuable inputs and validates the initial assumptions.
2. It also gives a clearer picture of  customer needs and competitive alternatives. Talking to customer gives a much deeper insight into actual customer usage models and needs - there are invaluable for defining new product features/functions. In my past experience, we had a case where got so impressed with the product idea that they were willing to invest and co-develop the product. Customer, being a Fortune-500 company, thus ensured the product was an overnight success.
3. It also helps to uncover new opportunities for differentiation from competition, and helps in clear market positioning and helps develop the product launch, and product marketing plans.
4. It will reduce or eliminate unnecessary features, thus it will reduce the amount of product that needed to be built, and speeds up time to market!
5. It is always better to be first in the market - even with minimum viable product. This reduces cost of development and time to market.

Customers are eager to help 

It is surprising to know that most customers are eager to help and talk about their needs - even to companions that don't even have a product.

During my interactions with customers, I have noticed that customer often tend to request features that are far more ambitious than their current needs and usage, but are willing to accept a product that meets their minimum needs.  As a result, we were able to release new product in months - and without many features which was initially planned.

Customer are also willing to give time for additional features - which helps in product road map definition. Just asking for customer priority of features helps in identifying the time scales for subsequent product releases and this also helps shape the future direction of the product.

Customer Involvement is actually an opportunity to build stronger relationships with some of our customers. We'll choose those most likely to be receptive, and we'll set expectations appropriately.

However, customer involvement does not mean building a custom product - which meets the needs of only one customer.  Its a process for gathering information, and it will require a skilled product manager to prioritize that information and figure out what and how we respond to it - and help product management do their jobs more effectively.

Customer involvement gives information on how individual customers behave and buy. This type of insights cannot be captured from market research or from usability testing. Market research and usability testing are still very imprint and customer involvement does not eliminate it.

Customer involvement is the best way to validate assumptions on who the customer is, what he needs and what he'll buy.

First steps in Developing New Software Products

Software Product development is much more challenging than software services. Product development needs much higher level of domain expertise, technological expertise and long term commitment to develop the product. In addition of technical competence it takes a very high level of marketing competence to succeed.

The initial team that is drafted to develop a new product will have to address various marketing and technical issues first - before starting the actual product development even starts (a.k.a. coding)

These steps are very important in new product development and must not be compromised upon.

Step-1: Product Definition & Product Positioning
Step-2: Product Features & Quality Imperatives
Step-3: Product Road map & Release Cadence
Step-4: Product Technology & Architecture
Step-5: Project Resource Plan
Step-6: Product Deployment Options
Step-7: Product Marketing Plan
Step-8: Financial Project Plan

Note that product development is a completely cross-functional effort. Software engineering, Technology, Marketing, Finance & HR management roles have to work together to build a successful product.

Step-1: Product Definition and Positioning 

The first step in software product development is the clear definition of the product:
What is the product?
What problems it will solve?
Who are the users?
What is competitive advantage?
What are the distinguishing features?

Answering these five questions will give a clear definition of the product itself - which is essential first step for new product development. Answering these questions requires deep domain knowledge and deep understanding the market needs. If product definition is not done properly, then the resulting product will be like a solution searching for a problem! (Which is bound to fail in market)

Step-2: Product Features & Quality Imperatives

Once a product is defined, the next step is to define the features and functions the product must provide. The product features and functions must be defined in terms of the intended users. For an enterprise product, this requires deep domain knowledge of (potential) customers and customer work flows. It is not uncommon to involve people from potential customer industries for this. For a consumer product, focus must be on good user experience while meeting the user needs.

In addition to user requirement features, there are other additional features that must be considered. Government regulatory requirements & Industry standards Requirements. For example HIPPA, SOX, PCI, DCI, ISI, ITAR, FCC, etc., are defined government and industry standards that the product must meet - else it will not be allowed to sell!

In an ideal world, one can develop a product which has all the required features and with best quality in time. However, real world imposes has its own limitations. Not all features can be developed in time nor can the product meet all the quality requirements. This implies a quality Vs Features tradeoffs.

As part of product features definition, the quality requirements must also be identified. One needs to answer: Is more like a Proof-of-concept? Or Is it an enterprise class product? Or is it a Consumer grade product? For each class of product - there are different quality imperative that must be addressed while defining the product features.

Step-3: Product Road map & Release Cadence

Once product features is defined, it will become clear that not all features can be developed in one release, especially in an complex enterprise product. Even in case of simple consumer product, the market conditions and user requirements will change with time - and the product needs to adapt to meet those changes.

Product with reasonable quality/stability and that can be developed in a reasonable time frame - form the first version of the product.

Other features & functions will have to be developed and released in a phased manner. This is called as a product roadmap. Product roadmap is an intended plan of how all the intended features will be developed and when it will be released.

Release cadence has to be defined in this plan - so that it give an indication as to when a particular feature will be released: is it coming in next 6 months or one year or 18 months etc. Having a planned releases helps in several ways: One, it helps in fixing bugs found at customer site, Two it helps in modifying features to better match user requirements, Third, it helps to add new features incrementally which that helps in project management and also helps to avoid scope creep on a single release.

Planning the product roadmap & release cadence helps in next steps.

Step-4: Product Technology & Architecture

In software product development, choosing the right product technology and platforms is very important and can make or break a product in market. In large organizations, a separate CTO - Chief Technology Office is often established, which determines the right technology choices. For example, when developing an enterprise application, choosing a right Database, choosing a right middleware, the OS platforms etc., - could make/break a product.

Software Technology also refers to development tools such as compilers, version control tools, testing tools, performance testing tools etc.

Software Technology also refers to choice of using opensource code or licensed utilities (JBOSS, Jinfonet etc.)

Product Architecture forms the foundation of the product. Depending on the intended market and time to market, proper architectural choices has to be made. Once the product architecture is finalized and product development starts, it becomes very expensive to change the product architecture. Product architecture has to be very carefully planned and designed.

When it comes to making choices of product technology and architecture, it is always good to look ahead and choose newer/scalable/flexible technology & architecture, so that, when needed,  changes or upgrades & addition of new features can be easily done on the product to suit market needs.

Product Technology and Architecture also determines the resources needed for new product development.

Step-5: Project Resource Plan  

Once the roadmap and features are identified, it is now easier to plan for the required resources needed to develop the product. In a software product development, the biggest resource are engineers & software development tools: Servers/computers & software tools.

Identifying the scale & timing of resources needed and by when helps in the next step: the Financial Project Plan.

Step-6: Product Deployment Options  

Software products often have several deployment options.  Typically, a consumer grade software product should work right out of the box. Customers should be able to install it themselves and start using it.

In the world of cloud & mobile apps, customer expect ease of deployment as a basic requirement. For such products, the product distribution platforms (App Stores, or Web Site or Retail distribution) has be decided.

In case of enterprise products - there is a whole lot of configuration & customization that needs to be done for each customer. In such a case, Product plan must also determine which of the features should be offered out-of-the-box and which features are to be customized at customer site. Ideally, all the common components should be out of the box and all customizable components must be done through config files - i.e., no compilation of custom code at customer site.

Identifying the product deployment options helps in Product marketing Plan

Step-7: Product Marketing Plan

Products have to be pushed to the customer or Customers can be induced to pull in the product from the distribution channels. The choice of Push or Pull determines the marketing strategy.

Some products can be sold via partnerships or by bundling with other products. For example, Microsoft can bundle Lync with its Office suite, SAP can bundle Hana with its R/3 Suite etc.  Google Maps gets bundled with Andriod etc.

In some cases, the product can be sold via partnerships. A partner company may choose to sell the software along with its suite of products. For example Cisco sells HP Opsware along with its suite of network management tools.

In case of pull strategy, customers have to be induced to buy the product. For customers to buy a product, they must first be made aware of the product - via advertisements or marketing communications, and if the customer likes what they hear about the product, they may opt to buy it. For example Apple Pages, or Whatsapp or WeChat, or Intuit or Turbotax etc. These products are heavily marketing via different channels and customers will buy from retail channels.

Selecting a right marketing plan has a big impact on determining the financial plan.

Step-8: Financial Project Plan

It takes money to develop new products. The total amount of money and the timing of expenses has to be carefully worked out and planned. In large companies, funding may not be a problem - provided the product business plan is complete & agreed upon by relevant stake holders. In case of small/medium size companies, finance will be a major constrain - which impacts every aspect of new product development plan.

Closing Thoughts

In this article, I have put financial project plan as a last step. In many cases,  financial plan becomes the first necessary step - which then determines the scale & scope of new product development projects.

For sake of simplicity and ease of understanding, I have presented Software product development plan as a 8 step waterfall process, which is an ideal situation. But in reality, all steps happen in parallel & in iterative process. Developing new software products is never such a clean & smooth process. It requires lots of deliberations and analysis - which will make these steps happen in parallel and also in iterative process - where each planning stage has to be revisited iteratively all through product development life cycle.   

Product Management: Manage Requirements for Project Success

India has been a major power in computer software, but lot of companies struggle to develop software products. I have seen a lot of start-ups struggle with new product development and after several months or years of efforts product development projects are canceled.

The major problem with Indian IT companies is that they lack proper product management skills and fail to properly manage the product requirements.  In this blog, I have listed the basic steps in managing requirements to ensure new product development success - particularly for start-ups.

All product development starts with identifying product requirements. The job of product manager is to define the product requirements and work with engineering and project management office to implement it.

Successful new product development is not an easy project and there is always chances of mistakes or missteps. From experience, I have noted down few mistakes that must be avoided in all projects.

The most common problem is that of project overruns. Often the project costs more than the initial estimate and/or takes more time to complete. To avoid getting the blame for the overrun, some teams try to release a half baked product. Which results in a much bigger problem of fixing the issues after the product release.

In this blog, I have listed the basic steps in managing requirements to ensure project success.

1. Document the minimum set of requirements that has to be met to ship the product.
2. Avoid misinterpretations of product requirements.
3. Do not 'Overbuild'
4. Define 'quality parameters' as part of product requirements
5. Define compliance as part of product requirements
6. Keep a close eye on project team coordination
7. Build an agile product development process
8. Avoid excessive changes to product requirements
9. Ensure Executive involvement
10. Ensure a Beta test program with a real customer.

Document the minimum set of requirements that has to be met to ship the product.  

Before starting the development project, the first step is to document the requirements in ways that can be clearly understood by the team. If needed, use visuals or animation or mock-ups to make people understand the requirements.

These requirements must also be prioritized into "must have", "Good to have",  "Bonus" etc. The final product cannot be released if it does not meet the "Must Have" requirements. Once the "Must Have" requirements are identified, then work on estimating the time & resources needed to complete the project.

Product managers & all stakeholders must review the product to check if all the must-have features/requirements are met before proceeding with the product release.

Avoid misinterpretations of product requirements

Understanding product requirements is always a challenge. Often times, the requirements are documented in plain text. Which can be misinterpreted, leading to chaos/confusion at the time of product release.

There are several levels of requirements that must be documented. Starting at the high-level of the product concept, Architectural details, and down to user interface design requirement.

The best solution is to document the requirements using visuals - either in terms of visuals or animations or mockups. In addition, one can create user personas to illustrate the end user requirements.

During the development process, ensure that the entire product development team has a common understanding of the requirements.

Do not 'Overbuild'

A common problem with building new products is to add loads of bells and whistles into the product or build capacity/capability which is far in excess of user's real requirements.

Another manifestation of this problem is to add too many features. In most cases, there is just one customer who needs that particular feature!  This leads to adding too many features which confuses customers.

Overbuilding a product costs money, time and resources - all that for features that customers do not want!

So care must be taken to ensure that the final product actually has what is needed.

Define 'quality parameters' as part of product requirements

Quality of the product must be defined in the product requirements. The quality is as perceived by the customer. For example, Mean Time Between Failure (MTBF) of the finished product must be defined in the product requirements. In case of software, the system stability, or memory growth must be defined in the requirements. The quality parameters such as "response time" or "resource utilization" etc. must be defined as part of the product quality.

Define compliance as part of product requirements

Just like quality parameters, the product compliance requirements too must be documented in the product requirements. Often times, I have seen that the requirement document makes only a passing reference to compliance adherence - and does not dwell deeper into the actual technical details of the requirements. Such high level description is a perfect recipe for disaster - as it opens up the field for misinterpretation of requirements.

Keep a close eye on project team coordination

Today, distributed project teams have become a norm. Even startups out source some segments of projects. In such cases, the team coordination becomes a major hurdle, leading to miscommunications and project over runs. Any signs of poor coordination is a red alert on things going wrong in the project.

As part of Product management oversight on the project, it is important to keep a close eye on the team coordination and take proactive steps to improve team coordination. Product management must work with project management and engineering teams to constantly monitor team coordination and take corrective actions as necessary.

Build an agile product development process

In today's rapidly changing world, it is important to be agile - not just in project management, but also in Product management. Agile product management helps in modifying the end product to meet the market needs - even when the project is under execution.

Agile product development allows product managers to fine tune product requirements and meet customer's changing requirements.

Avoid excessive changes to product requirements

While agile product development helps, excessive changes are detrimental to the product development. Especially, when changes are made to sections of the project that is already built/coded. So any change in product requirements must be validated and vetted by all stake holders. As a thumb rule, a project should not have more than two changes to requirements - to sections that is already completed, and any change must be approved by the change request management committee - a.k.a. stake holders.

After the second change request, any subsequent change requests must have an executive level approval.

Ensure Executive involvement

New products are part of the overall business strategy. So the top executives must get involved in new product development and provide strategic inputs when required. Top executives must also oversee the project and provide active project governance. In case of startups, when the founders themselves are deeply involved in the project - the board of directors must provide the higher level governance.

Ensure a Beta test program with a real customer.

Beta testing the new product with the customer solves a lot of problems in the product development stage and also improves customer satisfaction and user acceptance. Getting customers to test the product before release will help uncover functional bugs, design gaps and other user environmental issues which could not be found in the internal testing cycle. Often times, developers use simulators for testing - which does not reflect the actual customer environment. So the Beta test helps identify those bugs or even design flaws - which can be fixed quickly.

Remember: the cost of fixing a bug in beta testing is lot cheaper than fixing it after the product release.

Closing Thoughts

Project success is also dependent on managing requirements. Product Managers must keep a tight control on product requirements. Many Indian software startups try to build a perfect product and try to please as many customers as possible or try to add too many features/requirements. This leads to an unwieldy projects - which eventually fails.  In this article I have described 10 main points product managers must follow to ensure new product development project a success.

Project Management & Change Control

In any new product development project, the market conditions are constantly changing & hence there will be need for changes to the project requirements & deliverables even during the execution of the project. Successful project management is all about understanding the need for changes and dealing with it i.e, Deciding on when & how to make the required changes in the project.

Any change to the project requirements can have an impact on the project cost & schedule. It is therefore important to understand the importance of the change & the impact to the current project of the change is agreed upon. And once a change is approved, the project plan may have to be revised and the revised project plan will have to be communicated to all stake holders.

In the initial days of project management, it was the role of project manager to decide on the required changes, but today, it is common to have a larger group called as Change Control Board (CCB) to manage all the requested changes. CCB is a decision-making body controlling all project changes. The CCB must consider & review each planned or unplanned change. The name for this group could vary, but the function it provides does not. The main objective of CCB is to control the change process in a disciplined, visible, and traceable manner.

This article is about the role & process used by CCB.

Formation of CCB

Who should be the members of CCB? Ideally, the members of CCB should include the key stake holders & decision makers for the project. Ideally, the CCB consists of project/program manager, product/account manager (who represents the customer), Project's engineering lead, Project's QA lead, Product Marketing lead (for product development projects), Project's financial controller. Other members may be included - based on the project's specific needs.

Once the CCB is established, a standard process for the operation of CCB needs to be established. Normally, the CCB mechanisms are standardized by the PMO office.  The PMO office establishes the CCB charter and the rules of engagement at start of the project.

Planned & Unplanned Changes

As the project progresses, there could be changes introduced into the project requirements. These changes could be planned changes or unplanned changes.

Planned changes are those that occurs in the project from orderly progress of the project - i.e, as the project progresses from: (1) requirements definition, (2) preliminary design,
(3) detailed design, (4) coding, (5) production/deployment, and (6) operational use.  These planned changes in project do not have an impact on the project schedule.

However not all projects progress in an orderly fashion. Additional requirements may be added by the customer, or upon detailed design - new requirements/test cases are identified etc. Such changes are unplanned changes and may have an impact on project schedule.

CCB reviews all changes - planned & unplanned and constantly reviews the project cost & schedule impacts due to these changes. CCB also documents all the change requests and minutes of meeting for future needs.

Activities of CCB

Program Management office works with CCB to define the main activities of CCB. The main activities of CCB are:

1. CCB meets regularly to review all change requests. CCB members consists of customer or customer representative - so that the customer is aware of the review meetings & its decision. This provides the customers an insight into project progress to support more effective decision making.
2. Establish Norms for requesting any changes. CCB can publish a standards/templates to make any change requests.
3. CCB review & triage the impact of all change requests: Any addition or deletion of functional features, changes in project plan, project execution sequence etc. CCB may ask for impact analysis on the proposed changes from the execution team and based on joint review with customer or customer representative - may approve or reject the change request.
4. Upon triage of all the change requests, CCB can recommend project management to bundle up a number of small changes into one big change in the project and re-plan the project if necessary.
5. Once the change request is approved, the execution team implements the change & upon implementation, publishes a project change notice and documents the changes done in the project.
6. CCB should also review the project viability at every stage gate - as the project moves from one stage to another. This is the review of a planned change & the review is to see if the project is progressing as per plan and does the project makes sense to continue on.
7. CCB also publishes a change freeze date for the project. After this date, no change requests will be entertained. All proposed changes to the product development will be deferred to the next version of the product.
8. Record & document minutes of every CCB meeting for future needs. Program Management Office can use this records for future use.

Closing Thoughts 

CCB plays a very important role in project management, especially in new product development projects. When developing new products, there is a constant pressure from customers or product managers to add new features, but making that change can have adverse impact on the project schedule & costs. CCB acts as a judge, reviews the requested change and weighs the consequences and them makes the final call.

Program Management office establishes the CCB. The CCB provides a vital function in project management in managing all the changes to the project. CCB provides a controlled approach to deal with all the changes to the project requirements and works as a communication platform between the project team and customer.

Role of Program Management Office

Recently a Fortune-500 company started a new product development of a new software that will manage multiple data storage system and data management system run on a cloud. This was a multi-year endeavor. Developing the final product will require several software development projects, product integration and testing. The product will be developed by multiple teams working in many countries.

From a product development perspective, One of the major challenges here is project management. Managing a complex development and keeping everything on schedule is a huge task. In order to ensure successful development of the new product, Product managers will have to rely on Program Management Office(PMO), to oversee all the associated projects and present the overall program status to product management and top executives.

As product managers, it is important to know the role of PMO and the value it provides. In this article, I will describe the role of PMO in new product development.

Program Management Office

Developing complex products involves multiple projects. These projects have several interdependencies. The top management cannot dive into each project and understand the project operations, instead a Program management office is created as an intermediary between various project managers and top management to help top management make the right decisions.

The PMO is created with certain objectives:

1. Provide Business stake holders a complete dashboard on the status of each program.
2. Resolve & manage all inter-project dependencies.
3. Plan all project deliverables that are directly linked to strategic objectives
4. Prioritize and optimize the entire project portfolio
5. Ensure that all projects are handled in a repeatable & predictable process  i.e., establish standard process, methods,  tools and procedures to manage all projects
6. Communicate the program/project status across the business
7. Build & mentor project management capabilities
8. Own, Create and Manage project delivery infrastructure.

To deliver on these objectives, PMO is empowered to do the following:

1. Create PMO Process & Governance for all programs & projects
2. Develop standard tools, process, procedures & templates for all programs & projects
3. Maintain Chart of Authority
4. Create & review project benefits & value scoring mechanisms
5. Review Project opportunities
6. Communicate program & project goals
7. Prioritize and provide approval to projects
8. Review business cases for new projects
9. Manage project budgets
10. Approve or deny projects based on business case
11. Conduct check-gate reviews for each project with gate staging process
12. Approve & Coordinate inter-project communication.
13. Create & manage Change Control boards for each project
14. Review post project completion analysis
To ensure smooth project delivery, project managers who oversee individual projects have certain roles & responsibilities:

1. Identify Projects
2. Define benefits or values of the project
3. Gather supporting data and assumptions
4. Review business case alignment with project
5. Create project charter
6. Initiate detailed project planning
7. Monitor project progress & project resources
8. Communicate project status to PMO
9. Create & execute Change control boards
10. Close projects

PMO reports to the business management or product managers. The business management or product managers now have the visibility to the overall program status and can take appropriate decisions regarding budgeting, resourcing, staffing, Go/No-Go decisions etc. in a timely manner such that the project schedules are not impacted.

Value of PMO

PMO provides a very valuable role in business. PMO ensures that all projects are aligned with the strategic objective. PMO ensures that all assumptions made in the business cases are validated and appropriate decisions are made during the development stage in a timely manner. The benefits of PMO:

1. Empowers the business to make Go/Kill/Fix/Hold decisions on projects/programs
2. Provides an early warning of any potential problems in projects/programs
3. Provides all relevant project/program information to stake holders
4. Gives a better understanding of resource utilization, ensures right staff is deployed on the right projects
5. Helps stakeholders understand the financial impacts of an under performing project.
6. Optimizes resource utilization - by moving resources quickly based on accurate real-time information.
7. Helps board level executives to take better & faster decisions based on real time data.

Closing Thoughts

Identifying market opportunities and creating new products that exploit market opportunities can be a daunting task. Organizations can become bogged down with several projects and projects may get mis-aligned with the strategic objectives. Program Management Office is required to ensure that all the ongoing projects are aligned with the strategic objectives and empowers top management to take the decisions in a timely manner.

PMO plays a very important role is creating a repeatable & successful product development process, identifies project deficiencies and helps take the quick decisions as a team. This helps in a big way to make successful product development a repeatable process.

Writing a Good Statement of Work (SOW)

In the world of software development, bulk of the software being developed in customer software. Where the software is being developed to meet specific needs of only one customer. In such cases, the starting point for the project planning is the SOW and is fundamental to the success of the project.

Writing a good statement of work is no easy task. Having an vaguely worded SOW is an invitation for a project failure and is often the reason parties end up in a dispute.

A best practice is to have a joint team from both the developer & customer organization to write an SOW. This will reduce the likelihood of conflicts during the project startup stage.

From project management perspective, a good SOW must have the following features:

1. Background

The SOW should explain the background of the project explaining why the project is necessary and critical for the organization. Having the business background for the project is important so that everyone in the project team understand the bigger picture and the goals for the project, i.e., the project success criteria must be clearly articulated in such a way that every one in the project team understand what has to be accomplished.

The SOW sets the context of the project by defining the purpose, objectives, scope, constrains, assumptions and reference documents.

2. Points of Contact

Specify points of contact, including who will be the customer [project] managers interfacing with seller personnel during work accomplishment. At a minimum, a point of contact who has decision-making authority during work accomplishment should be specified. This individual will participate in CCB meetings and will be empowered to provide direction to the seller during work accomplishment.

3. Task Specifications & Deliverables 

This is the main section of the SOW. The SOW should specify the individual tasks that has to be done by seller/developer and by the buyer/customer. In a custom software development, there will be inputs & tasks to be done by the buyer.

For each of the tasks, there must be an associated deliverable, which lists out when & how that task is associated with the list deliverables. The SOW must also list out the dependencies (if applicable) for each task.  These tasks will be rolled into the project plan.

All deliverables must have specific dates. But this date could be changed only upon the approval from the CCB.

4. SOW $$ Value

The SOW should have financial information:

1. Total value of the contract
2. Payment terms, schedules & conditions.
3. Limits for certain types of expenses.

The financial information provides the limits of the project and gives the buyer an idea of the total costs involved. The pricing of such custom software development projects can be in terms of: Fixed Price or Time & Materials billing. Financial terms sets the ground for project planning.

5. Project Life Cycle

Though SOW is written for a one-off development, there could be multiple deliverables and maintenance works associated. Defining the life cycle of the software being developed will give developer and buyer various options for risk mitigation, and also gives greater flexibility to add new features as business conditions change. For example, customer wants a billing system to be built and maintained for a period of 5 years. During the period, vendor/developer is asked to release patches & upgrades every six months. This system will give greater flexibility for the buyer in terms of getting new/additional features, and also serves as a risk mitigation strategy in cases where when there is a feature schedule slippage, or when customer finds a bug in actual production usage.

6. Change Control Board

Change Control board and Change control mechanism must be explicitly defined in the SOW. The change control mechanism must be understood by all stake holders & team members. All changes to the initial SOW must be approved by the CCB and must be documented and tracked to a particular change request ID. CCB also provides as a channel for customer-vendor dialogue and interactions.

7. Risk Assessment & Risk Mitigation plan

SOW must have section in which the known risks at the start  are documented and appropriate risk mitigation strategy defined. For example, changes to taxation rules could be risk to the billing software project. In addition, the SOW must allow the seller to assess the risks involved in accomplishing the work as per SOW.  The Project plan will have the complete risks documented and risk assessment plans documented.  Also see: Risk Assessment in Software development

8. Joint Project Management Office

Since custom software development is a joint activity of the buyer & developer, a joint project management office will be required. The working details, authority & responsibility between the buyer & developer must be documented in the SOW. Having a pre-stablished Project management policies will help speed up decision making during project execution.

9. Existing Seller Practices

Today majority of software service providers e.g.: IBM, HP, Accenture, CSC etc have an established engineering practices and organizational policies and procedures that sellers are supposed to follow. The SOW must have a reference these items. Developers follow their internal policies & procedures and this in some cases may impact the project or may be impractical for the project or could be in conflict with the buyer's policies.  So having an clear reference to the vendor practices, policies, & procedures will help avoid future conflicts and when required the SOW can specify which of the vendor practices, policies, & procedures that must be changed or waived for this current development.

Closing Thoughts 

In the world of custom software development the SOW is the starting point for the project. Having a well defined SOW is critical for the project's success. In many cases, there will be master agreement between the vendor and buyer, which provides details on Joint Program management policies, pricing & payment mechanisms, and project governance details. In such cases, the SOW should have a reference to the relevant sections of the master agreement.

Having a well defined SOW forms the solid foundation upon which the project will be completed.

Overview of a Project Plan

Releasing new software products, on-time and on-budget, represent a significant investment for an organization.  Because of the critical nature of software products on company's profitability, more attention needs to be paid to effective project management and how it impacts the overall business strategy.

Releasing products on time & on budget should not be a "one-off" isolated event, but a repeatable & predictable aspect, and a core business capability that drives the profitability of the business. 

Releasing products on time is a core project management function and the effectiveness of an organization's project management process can make or break the bottom line of the business. 

With this in mind, stakeholders are demanding greater accountability in the way projects are managed and demand full visibility into the project plan and project status. To ensure successful project, Project managers work with the program management office (PMO). This article provides an overview of a ideal project plan needed for software product development.  

The Project Plan

An ideal project plan has seven main sections.

1. Project Overview

2. Risk Assessment & Risk Mitigation Plan

3. Project Governance Plans

4. Development Plans

5. Quality Assurance Plans

6. Project Work Schedule

7. Project Resource Plans

1. Project Overview

Project Overview sets the context of the project by defining the purpose, objectives, scope, constrains, assumptions and reference documents. 

Product Requirement Document is usually the starting point for the project. The PRD defines the product functions - which translates into project objectives, project scope, and project timelines. Project managers then work out the project constrains,  and assumptions.

The Project Overview should have the statement of purpose of the project. This helps communicate the high-level understanding to all stakeholders. The project overview should also have the background of the project explaining why the project is necessary and critical for the organization. The goals for the project, i.e., the project success criteria must be clearly articulated in such a way that every one in the project team understand what has to be accomplished.

The project scope - i.e., the boundaries of the project must also be defined in the project overview. The project scope clearly tells what will be done and what will not be done, where ever it is needed - for example work allotments for contractors etc.  Things outside the project scope will not be done and planned for. Project managers must constantly monitor and prevent out-of-scope activities.  

Once the objectives and scope are defined, the project assumptions & constrains are listed. This assumptions and constrains become the basis on which the project plan is written. If the assumptions turnout to be wrong, the project plans will have to be changed accordingly.

2. Risk Assessment & Risk Mitigation Plans

Once a PRD is presented to project management office, PMO starts the Risk assessment and develops the Risk mitigation plan. All projects have to be classified into High, Medium & low risk projects. For more details on project risk assessment see: (http://arunkottolli.blogspot.in/2012/09/risk-assessment-in-new-software-product.html) 

Once the risks are identified, the risk mitigation plans must also be developed and documented for each of the identified risks. The risk mitigation plan may involve changes to project schedule or release plans.

3. Project Governance Plans

The project governance plans defines the management oversight, coordination and review activities for a project. In most cases, the project governance plans may not be explicitly called out in a project plan because there would be an established Program Management Office (PMO) - whose main job is to provide management inputs to the project. Even in such cases there are few specific details of management plans will have to be published in project plan. Such as:

1. Project Team Organization: The size of the project team, Names of team leads and other key personnel.

2. Contractors (if any)

3. Reporting structure for all project personnel.

4. Frequency and schedule of Management Oversight & review meetings, status reviews.

5. CCB members and frequency of CCB review meetings

The PMO provides various management functions for the project: Resource allocation, budgeting, review business case, Project review, validate project assumptions, standardize tools & process etc.

4. Project Development Plans

Project development plans define how the product will be developed. It contains details on how the development team will develop the product that meets the PRD. This lists out all the efforts involved, all the development tasks that has to be accomplished, tools used. Typically, the project is divided into stages and list of  tasks to be done in each stage is listed out, along with milestones to be achieved and deliverables for each stage. 

For software product development projects, development activities include defining OS/System Platform requirements, allocating hardware and software tools needed, high level design describing data flow, conducting design reviews, product documentation, code reviews, providing training for operational use.  

Developmental stage leads the quality assurance stage.

5. Quality Assurance Plans

The quality assurance (QA) plans are a set of tasks that are required to ensure that the final product meets the PRD. QA plans details the checks and balances to be used to help ensure that each developed software product satisfies the defined requirements. 

The QA plans also lists out the checks and balances that are in place in form of quality assurance, verification and validation, test and evaluation, and configuration management. The QA plans are detailed for and tied to the development tasks - i.e., every developmental task must be tied to a QA task. 

In software product development, QA planning status with examining the PRD for congruency, testability, and consistency; preparing test plans; writing the test strategy; determining standards conformance; completing test procedures; conducting acceptance testing; performing test procedures in the operational environment; base lining products; and archiving incident reports and change requests.  

Product QA activities include defining test strategies and test data; comparing prototype requirements with the skeleton prototype; preparing acceptance test procedures; preparing beta procedures, preparing product acceptance testing and customer acceptance.

The QA plans supports the product development plans and provides management an insight into the status of the product development activities. 

6. Project Schedule.

The project schedule contains the complete schedule of the project as its stands on that day. At the start of the project, an initial schedule is planned out and as the project develops there could be changes in the plan. The project schedule captures the current schedule and the original planned schedule for documenting the project progress and post project assessments.

7. Project Resource Plans

Project resource plans identified all the resources required to complete the project. This includes all people, tools, hardware resources etc. Project resource plans document the initial resources allocations and actual usage for documenting the project progress and post project assessments.

Closing Thoughts

Detailed Project plan is the first  indicator of the preparedness for project success in any new product development projects. As product manager, I look at the project plan as a key indicator of how work is progressing and plan for next steps accordingly.  The absence of a detailed project plan is a leading indicator of an impending failure. The level of detail in the project plan is vital in taking right decisions for the success of the project. 

Risk Assessment in New Software Product Development Projects

All new Software product development plans involve risks. These risks must be handled and managed using project management techniques.  From a project planning perspective, risks is classified into high risk, medium risk, or low risk, and appropriate risk mitigation plans has to be developed. Project risk management is a complex subject and has several nuances. However for simplicity of understanding, this article will deal with risk assessment from new product development perspective.

At the high level, the risk for any new product development project can be classified into:

1. Probability of the product not delivered on time.
2. Probability of the product not developed within budget
3. Probability of the product not having all the required features or not working as intended.

The job of management is to assess the risks and develop risk mitigation strategy.  With good management and product development process, all risks can be assessed early in development process and eliminated by proper allocation of resources.

A good approach for risk assessment includes:

1. Establishing a set of risk assessment criteria derived from both the organization's experience and industry wide data.

2. Consensus among all the parties involved - i.e., Product manager, marketing, finance, engineering, QA, &  project manager etc. The entire team agrees on the various risks involved in the project.

Based on this assessment, the project risk is usually classified into High(> 30% probability), Medium (> 20% probability) or Low risk ( < 10% probability).

It is important to establish a company wide database of risk criteria for your software systems development projects. In large organizations, office of program management maintains this and is primarily responsible for risk assessment.  The risk assessment logic can also be applied at each individual task level, sub-task level, etc. Furthermore, as the project unfolds, this logic can be applied on a periodic or event-driven basis as a part of your overall risk management approach.

Once the risk assessments are completed, the product team: Product manager, marketing, finance, engineering, QA, &  project manager etc., is responsible to developing the risk mitigation team.

Often times the risk mitigation plan would involve adding resources to the area that has high risks. If additional resources does not mitigate the risk, then in some cases certain requirements may have to be modified.

Risk Criteria

The main outcome of risk assessment exercise is to identify all the risks involved in the project and based on the set of risks, the project is classified into High, Medium or Low risk project.

1. High Risk Projects 

Projects that have more than two of the following risks identified, then such product development projects are usually classified as high risk project:

In case of new product development which is developing a "new-to-world" or "new-to-company" type of products - the risks are always high due to:

1. Unique product
2. Lack of clear requirements documentation.
3. Inexperienced development staff
4. No clear QA & test plans
5. Unknown customer use cases
6. Financial constraints
7. Technical challenges such unavailable technology or tools, etc.

Even projects that have high levels of subcontractor labor - with at least 50% of total development labor should be treated as high risk projects - due to less management oversight, lack of labor flexibility, and over dependence on subcontractor.

The project must be classified as "high-risk" if the product is a mission critical product - i.e., the failure of the product leads to death or injury or very large financial losses.  For example failure of Control system products can lead to death or injury during testing, Financial trading software that can lead to big losses (like the one that brought down Knight Capital.  Knight Capital lost $440 million in 45 minutes of trade.

Such high risk products must have extensive beta testing programs before they can be released.

Even projects that are just new revisions of an existing product can become high risk project if:

1. Development or QA resources are not fully committed.
2. Product requirements are not fully defined.
3. Project funding is not secured - i.e., management team is not in full agreement for the project.
4. There is no slack or buffers in the project schedule.

Once a project is identified as a "high-risk" project, full commitment from all stake holders is required for risk mitigation. Without total commitment from all the stake holders the new product development project is doomed to fail. In such a case, the project must be kept in abeyance till all stake holders agree and give their full commitment.  

High risk projects demand a very close monitoring of project and project risks. High risk projects require a greater commitment of resources - perhaps in form of reserve pool of resources being identified and kept ready for rapid deployment if needed.

High risk projects also require high levels of testing, Quality assurance and on-site validation. For high risk projects - about 65-75% of the total efforts are allocated to testing & quality assurance.

Risk mitigation plans for such high risk projects are almost always never complete, and with the risk materializes, the management team will have to tailor/modify risk mitigation plans.

2. Medium-risk projects 

Medium risk projects are usually the average software products that are:
1. Another revision of a current product.
2. Does not play a mission critical role at customer site
3. Customer has no critical dependency on the product
4. The functionality of the product is well understood.
5. Developer has some flexibility on release dates
6. Product has few fall back options: reduce functionality or release a patch after the release etc.
7. There is no over dependence on subcontracted labor (i.e., subcontracted labor is less than 50%)
8. Most of the project efforts are in product development - i.e., to add new features.
9. Failure of the product at customer site results in a negative publicity for the product or/& company.

Routine product enhancements can also become a medium risk project if:

1. The development or QA staff is inexperienced
2. Product testing procedures or resources are inadequate for the new features
3. There is little slack or buffer in project schedule
4. Requirements are not fully understood by the development team
5. There is uncertainty in product requirements - either the PRD is not fully developed.
6. There is dependency on external partners or vendors
7. External Market conditions are uncertain - i.,e possible recession etc.

Medium risk projects have to be monitored with pre-approved risk mitigation plans. These risk mitigation plans must be exercised immediately when needed to avoid  project failures.

3. Low-risk Projects

Projects that are not classified into high risk or medium risk projects are by default low-risk projects. In Low risk projects:

1. Product requirements are fully understood.
2. Have experienced development staff.
3. Have flexible schedules
4. Product failures do not cause any losses & can be easily rectified with a patch releases.

In low risk projects, most  (> 80%) of the resources are allocated for product development and has no allocated reserves. Usually teams/resources for low risk projects are identified as reserve resources for high risk projects, and such resources can be quickly redeployed for high risk projects - if there is a need.

Risk Mitigation planning

In most of the cases, risk mitigation plans translates to identification of additional resources that can be used when needed. In reality, most organizations are stretched for resources and often will have nothing to spare for a high risk project. In such cases, Management is running on hope & luck - to see the project through. Failures in such situation will be disastrous - often at an enormous cost. Many startups die because they cannot afford resources for risk mitigation. Even in large companies, projects get canceled when there are no resources for risk mitigation.

As a prudent management planning, companies today are using the option of killing the product development projects are part of their risk mitigation strategy. In mission critical projects, it may be prudent to kill the product if the risks become too high.

Closing Thoughts

It is important for all stake holders to be involved in the risk assessment process & achieve consensus on project risks. Risk assessment starts with the product definition stage, right at the time of developing the product requirements and then working as a team to develop plans for risk mitigation.

All stake holders must have full visibility to risk identification, risk assessment and risk mitigation plans. This leads to better understanding of the risks associated with the new product development projects and thus allocate the right resources needed for successful new product development.

Risk mitigation plans are almost always never complete, mainly because, resource estimating is, at best, educated guesswork. So when a project risk materializes, the entire management and project teams will have to work to mitigate it. This often needs heroic efforts from few individuals.

Product managers must be prudent to kill the project when necessary. Many a times it is better to kill a project than throw more resources at a doomed project. This decision of killing a project is more of an art than science.

Product Management and Software Product Development Lifecycle

Software product development is a complex activity and product managers play an important role all through the product development cycle. As companies mature, a standard way of new product development is developed. Product managers will have to focus on internal product development process along with focus on customer requirements and market conditions.

The product development activity is internal to the organization and from product management activities perspective, it is often referred to as "Inbound Product Management". This article is a brief description of all what roles product management plays in the product development life cycle - a.k.a "Inbound Product Management".


Typical software product development lifecycle consists of six distinct stages:

1. Requirements definition
2. Product design
3. Product Development  & QA
4. User Acceptance or Beta program
5. General release
6. Operation & maintenance

Product management plays an important role in each of these six stages.  In this article, I will briefly go over the activities done during each of the six stages.

Requirements Definition 

Requirements definition stage focuses primarily on what the final software product should do. This is often documented in terms of what functions to be performed,  on what platform (hardware/software & other dependencies) This may include performance details, functional details, serviceability details etc..

Each requirements must be prioritized and ranked in the Product Requirement Document (PRD). External dependencies, if any, must also be listed - so that proper project risk assessment can be done.  The requirements must be "unambiguous," "complete," and "traceable."

The PRD must be written in such a way that both development and quality assurance teams must be able to understand the requirements in its completeness,   consistency, stability, verifiability, modifiability, and traceability.

Project management takes this PRD and develops a project plan based on effort estimations and estimated risks. Once the PRD & project plan is approved, any change to the product requirements or project plan must be approved by the change control board. The project management tasks include monitoring the assessed risk and planning risk mitigation strategies as needed. As the project goes into execution, project management refines planned budgets and schedules.

Note that it is very important to establish the change control board (CCB) early in the project planning stage. As the project progresses, both the requirements and product designs get further refined.

As the project proceeds, the various project dynamics result in the need to refine the requirements or the design implementation. Any change to the agreed-upon project plan must be presented to CCB and it is the duty of CCB to approve or reject the proposed changes. The CCB meetings continue throughout the product development life cycle stages.

In some organizations, CCB function will be done by Program Management Teams (PMT) or/and by Program Leadership Management Teams (PLMT)

Product Design Stage

The main activity in this stage to define how the software accomplishes the stated requirements.

A specific requirement can be implemented in several different ways, it the software architecture and design teams responsibility to decide on how the system must be designed to meet the specific requirements including:

1. Hardware & Software platform definition
2. Defining all major systems & subsystems
3. Splitting of functions across different Systems or subsystems.
4. Data-flows into and out of different Systems or subsystems.
5. Defining data transformations in each System or subsystems.
6. Defining Algorithms & Design for Systems or subsystems.
7. Defining system validation methods for Systems or subsystems.
8. Defining quantitative performance measurement & evaluation criteria.
9. Design to confirm to various standards
10. Developing test procedures & test strategy.
11. Product documentation plan
12. User Acceptance Or Beta program Plans

In addition other design activities may be required depending on the type of software being developed.

The designs are then submitted to management team for approval. Once the designs are approved, any changes to the design will require explicit approval from CCB (or PMT/PLMT)

The product management tasks is to understand the design and how the design meets the customer requirements. Product managers play the role of customer and give valuable design inputs during the design phase.

The role of project management is to monitor closely the schedules and refine the project plan, Identify dependencies & project risks. Many times the product design work does not finish as planned and the product schedules are affected. Project planning activities should account for such potential schedule risks.

Product Development Stage 

In software product development, the main activity in this stage is mainly coding and testing. The main objective in this stage is to convert the detailed design into language that computer hardware can understand and perform.

The product management tasks is to monitor the development process and deciding whether the computer code is ready to ship to the customer. As software development progresses, there will be bugs: i.e.., defects and implementation variance from the actual design. Some of these bugs are show stoppers, some are critical and some are minor. Bugs are often classified based on severity: Sev-1,2,3,4 etc..

Management function is to determine the severity of the bug and then decide on whether the software is ready for release.

These management decisions are made at CCB meetings in presence of quality assurance team, engineering development teams, product marketing and all stake holders. The stake holders define the "acceptance criteria" and then make the final call on when to release the product.

User Acceptance Testing or Beta program

In User Acceptance Testing (UAT) or Beta program stage, the software product is actually deployed and tested in customer environment. This is a product assurance task where the customer and developed will examine the software for mutual approval.

Often times, the internal testing and quality assurance procedures may not be able to replicate the complex customer environments and customers may need time to really use and test the product before buying it. From product development perspective, customer acceptance is the ultimate quality assurance - implying that the newly developed product meets the stated requirements.

The beta programs can be extensive - running into several months, or a short cycle to test out certain new features, depending on the software maturity and reliability.

Product management tasks in this stage include monitoring the delivery of the product to the customer and soliciting customer feedback, improving the product based on the feedback. This may include tailoring the product or the customer environment - if the product is intended for a range of customers with specialized needs. Many enterprise software products (e.g.: SAP, Oracle, etc..) may require changes in customer's system environment to make the product work. These customizations and customer validation will be done in this phase.

Successful completion of this User Acceptance Testing or Beta program includes

1. Developing software systems that meet customer needs - including all customizations and system changes.

2. Packaging the final tested software code along with user documentation. All customizations and changes must become part of the final product.

Today companies capture the "golden image" of the OS, supporting databases, servers etc. into a shrink-wrapped system software - that can be deployed off the shelf for each custom deployment. This helps in operational & sustenance stage.

General Release

Once the software product completes the UAT or quality acceptance testing, the finished product is then released for distribution. Software is often distributed in form of physical kits - which consists of installable code, product documentation & license keys. Software products are now being distributed over Internet - where customers can download the entire product.

Product Management activities during this stage include training the users or in many times training the trainers, conducting product road shows, product demos and various product marketing activities.

The general release also indicates the end of the software development project, project teams & CCB are disbanded.

Operation & Maintenance Stage 

The main activity in this stage is to support customers' use of the product. Customer support groups are actively involved in educating customers to use the product, collecting product feedback from customers, documenting product bugs & providing fixes.

As the main activity in this stage happens at the customer site, product mangers must monitor operational use of the product, collect customer feedback, collect customer suggestions on product improvement, compiling and analyzing customer feedback and determining potential follow-on work.

A byproduct during this stage is customer detection of latent software defects and customer definition of enhancements or new capabilities that helps define the next product development cycle.

Closing Thoughts

Product development is often thought as an ongoing cycle of continuous development where one version of the software replaces the older version. From a product development lifecycle perspective, this is partially true. Product management can implement a phased development of new features through multiple releases - and thus minimize the risks and also enhance product acceptance in the market.

Eventually, all products will reach its logical end - i.e., no more new development, and then enter the death phase, where all product functions are also stopped. Product managers play a very important role in determining when to terminate a product. Usually product termination is also carried out in a planned and phased manner called as "End-Of-Life" (EOL) planning.

See: Software Product Management  & Product End of Life