Which companies are the main competitors in the GRC (governance, risk, and compliance) software industry and what are their respective stren

Which companies are the main competitors in the GRC (governance, risk, and compliance) software industry and what are their respective strengths and weaknesses?

 

Which companies are the main competitors in the GRC (governance, risk, and compliance) software industry and what are their respective stren

None

Which companies are the main competitors in the GRC (governance, risk, and compliance) software industry and what are their respective strengths and weaknesses?

 

Is there any way to reset my Facebook personal upload email address?

To find Your Secret Facebook Upload Email Address

• Open Facebook Mobile.
• Click Send my upload email to me now under Upload via Email.
• Pick an email address you access from the device you want to use to upload under Email Address:.
• Click Send email.
• Now click OK.
• Open the email from "Facebook " with the Subject "Facebook Upload Email".
• Copy the email address from the message text.
• Save it to your address book under "Facebook Upload", for example.
• You may also be able to add the address to your contacts using the attached vCard file.

To Reset the address

• Open Facebook Mobile
• Select Find out more under Upload via Email.
• Now follow the refresh your upload email link under Tip.
• Click Reset.
• Now click Okay. You're done

Is there any way to reset my Facebook personal upload email address?

 

CMMi – Requirement Development Part – III

So, what next…well lot of things still left in requirement development, and I guess you are enjoying every bit of this.

After coming up and deciding on every requirement, the components, and associating requirement with product component next in line for us is:

Now we need to analyze and validate our requirement, which give us variety of other question to answer:

How are Operational concepts and scenarios developed and maintained?

This would mean: During the requirement development phase, you should come up with various scenarios, all these scenarios should be augmented with quality attributes.

A scenario is typically a sequence of events that may occur during the use of the product or project, which is used to make needs of the stakeholders as ‘Explicit’. An operational concept for a product usually depends on both the design solution and the scenario.

You need to have FSD (‘Functional Specification Document’) at this stage.

Requirement Development - Engineering

The next question that arise at this level is:

How you define the functional requirements?

Definition of functionality, which is also referred to as “functional analysis,” is the description of what the product is intended to do. In simple terms what do you mean by Functional analysis, which will term as the “Required” functionality of the project / product. The definition of functionality can include the actions, sequence of those actions, inputs required for those actions, outputs, or other information that communicates the manner in which the product will be used.

You need to have FSD (‘Functional Specification Document’) at this stage. <<To be specific you should focus on IDD (Interface description document), and ICD (Interface Control document) which are part of your FSD>>>

Once we have functional specification document, next question we should ask from ourselves is:

How do you analyze whether the requirements are necessary and sufficient?

At this stage we analyze the requirement. We look at the design and talk about feasibility from requirement perspective, or which requirement affects feasibility.

You need to have Requirement Defect Report at this stage, supported by peer reviews comments, proposed requirement changes which will eventually have a change log.

Once we have identified and analyzed the requirement, this is the time for asking few more questions:

How do you analyze whether the requirements balances the user needs and constraints?

Make sure you’ve result of all the conversation, and proof of records showing analysis and negotiations of tradeoffs between requirement, cost, and schedule etc.

And now the last but not the least question:

How do you validate the requirement that your product will meet the user’s needs?

Requirements validation is performed early in the development effort with end users to gain confidence that the requirements are capable of guiding a development that results in successful final validation.

At this stage be ready with Design docs, Simulators, Analysis etc.

Related articles

• CMMi – Process Area – Requirement Development – Part I (seeingfuture.wordpress.com)
• CMMi – Requirement Development Part – II (seeingfuture.wordpress.com)

 

CMMi – Project Planning – Resourcing

Image via Wikipedia

Ironically, though resourcing the product team members is a very important and significant part of a project manager’s role, not much focus is placed on resourcing. Because of this, we’ve encountered many project managers that are overwhelmed, worn out, and in many ways, well ineffective. Who to blame for?

In my own projects, I have been so very little blessed with good resourcing, and I am not talking from the perspective of ‘Skills’, I’m talking about manpower! 30% here, 10% there, 10 % I don’t know where, and remaining 50 % of the same resource already is planned for some other projects! Seems familiar…wow! look at the smiling faces of few PMs around

So rather than giving ‘Gyan’, let me ask you a very simple question, and before that; Resourcing is not just ‘Man-power’, resourcing includes, but not limited to, manpower, equipment, methods etc. So my question would be:

How do you plan for the necessary facilities? How do you plan for the necessary staff?

The top-level WBS, remember we developed it under estimation mechanism is typically explained / expanded by decomposing the top levels into small workable items that that can be separately assigned, performed, and tracked.

Now as this may be seen as additional work, but believe me, always remember to ‘Break-it-down’, this is so very important in our estimation and resource allocation methods.

You can or in fact should assign WBS a unique identifier (e.g., number) to permit tracking. A WBS generally is based on requirements, activities, work products, or a combination of these items.

So to answer the question that I asked, You do it this way:

You can provide excerpt from Project Plan (Say Project Delivery Approach), the MS project plan, or any other means of WBS of the project plan that identifies the need, available tools, schedule and budget etc.

You should provide excerpt from Project Plan that identifies staffing need, available staff resource, and plan for recruiting etc.

Scope of Work - MS Excel Work Breakdown Structure template (Photo credit: IvanWalsh.com)

Related articles

• CMMi – Project Planning – Identify Risk (seeingfuture.wordpress.com)
• CMMi – Project Planning – Estimation Continued! (seeingfuture.wordpress.com)
• CMMi – Project Planning – Estimation (seeingfuture.wordpress.com)
• Project Plan – How to Budget and Schedule! (seeingfuture.wordpress.com)

 

CMMi – Project Planning

From today onwards, we will see what are Process areas (Like Project Planning, Requirement Management etc.) and how we are going to get these implemented with in our Organization.

Let’s understand this:

At maturity level 2, the projects have

• ensured that processes are planned and executed in accordance with policy;
• the projects employ skilled people who have adequate resources to produce controlled outputs;
• involve relevant stakeholders;
• been monitored, controlled, and reviewed;
• been evaluated for adherence to their process descriptions.

This is very important to understand that Maturity level 3 contains all the elements of Maturity level 2 and additional for level 3.

Now as we understand the maturity level 2 have got defined policies, resources, stakeholders, and evaluation procedure. This is so very cool…so far…

Also at maturity level 2, the status of the work products (Example will be Requirement documents, Functional Specs time sheets etc.) are visible to management at defined points (e.g., at major milestones , at the completion of major tasks).

Product

—A work product that is intended for delivery to a customer or end user. The form of a product can vary in different contexts. (See also “customer,” “product component,” “service,” and “work product.”)

Work product

—A useful result of a process. This can include files, documents, products, parts of a product, services, process descriptions, specifications, and invoices. A key distinction between a work product and a product component is that a work product is not necessarily part of the product.

We intentionally are not following a step by step “Alphabetical flow” to understand all this. Best is to start with what we do daily in our life, that is planning. Most of us have been involved in Project Planning and associated activities with this, so let’s talk about the same:

But before we do, let’s see what all is contained within the project planning process i.e. PP as a process area:

Project Planning

Now while you are looking at this, let us explain a bit about the terminology:

SG: Specific Goals

SP: Special Practices

All rightie so all set! I am…Let’s get started….My first question to all of you:

How is WBS (Work Breakdown Structure) established.

How are changes to this are controlled.

How is it used?

Cheers

Related articles

• CMMi – Tailoring the processes! (seeingfuture.wordpress.com)
• CMMi – Capability Model (seeingfuture.wordpress.com)
• CMMi Process areas and mapping with Maturity levels (seeingfuture.wordpress.com)
• CMMi – Maturity Levels – Initial – Managed – Defined (seeingfuture.wordpress.com)
• CMMi – A crash course – Introduction to Dev 1.3 (seeingfuture.wordpress.com)

 

Product Opportunities Assessment

Opportunities for new products exist all around us, in every market, even mature markets. This is because what is possible is always changing. New technologies are constantly emerging, new people with new talents join your company, and competitors come and go. The product manager must be able to quickly evaluate opportunities to decide which are promising and which are not, and for the ones that look appealing, which ones should be pursued, which are best left for others, and which ideas are not yet ready for productization.

In many companies, it just comes down from above that we really need to do this product. In other companies, the marketing organization determines what products are needed.

In either case, too often the process of deciding whether or not to build a product is left to intuition (or worse, a large customer will offer to fund a “special” and this becomes the basis for a product effort).

Typically someone on the business side or in marketing will create some form of a Market Requirements Document (MRD) that is intended to describe the problem to be solved, and usually includes a business justification as well. The purpose of the MRD is to describe the opportunity, not the solution. At least that’s the theory. In practice, many companies don’t really do MRD’s, or if they do, they’re essentially product specs that are called MRD’s. When true MRD’s are done, they suffer many of the same problems as PRD’s – they take too long to write, they aren’t read, and they often don’t answer the key questions they need to.

The result is that many product managers ignore the MRD. But the problem with not doing anything and just jumping right into the product is that it is generally a good idea to look before you leap. The challenge is to do this in a quick, lightweight, yet effective manner.

I consider this “Product Opportunity Assessment,” as I prefer to call it, an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is either to a) prevent the company from wasting time and money on poor opportunities; or b) for those that are good opportunities, to understand what will be required to succeed.

Fortunately, it’s really not that hard to do a useful product opportunity assessment. I ask product managers to answer ten fundamental questions:

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. What alternatives are out there? (competitive landscape)
5. Why are we best suited to pursue this? (our differentiator)
6. Why now? (market window)
7. How will we get this product to market? (go-to-market strategy)
8. How will we measure success/make money from this product? (metrics/revenue strategy)
9. What factors are critical to success? (solution requirements)
10. Given the above, what’s the recommendation? (go or no-go)

The hardest question to answer is usually the first, which surprises people because it sounds like the easiest. But ask most product managers what problem their product is intended to solve, and you usually get a rambling list of features and capabilities, rather than the a crisp, clear and compelling statement of exactly the problem that’s solved.

Another difficult problem can be in assessing the size of the opportunity. You can get thoughts on this from industry analysts, trade associations, your finance staff, and from your own bottom up calculations. This is a topic in itself, but for now just remember to be conservative and realize that not every opportunity needs to be a billion dollar market.

The “go-to-market” strategy is especially important as that describes how this product would be sold, which can have very significant impact on the product requirements.

The solution requirements refer to any special needs or requirements that were identified during the investigation. Again, we’re not describing the product here but rather making clear any dependencies or constraints. For example, if this is a product that will be sold through system integrators, then these types of partners have requirements around extensibility of the products they deliver. Similarly, there may be branding or partnership requirements.

A product organization is all about pursuing good opportunities and providing great product solutions. Opportunities for new products are everywhere, and it is important that the product manager be able to effectively evaluate new opportunities and identify those that have the most potential for the company. It is just as important that bad product ideas get identified at this stage, before significant time and cost is lost chasing them. Choosing the right set of products to pursue is among the most important decisions a company will make.

It is important that the results of the product opportunity assessment be presented and discussed with senior management, and that the company make a clear go or no-go decision on whether to pursue a product to meet this opportunity. If you do decide to proceed, you will be much better informed as to what you are getting yourself into and what it will take to succeed.

So what do you do if the CEO tells you that this is what we’re doing, so just get to work on the product? First, realize that there are sometimes strategic reasons for doing a product, so you might need to pursue a product even when it’s unlikely to succeed in the market. That said, I have found that doing this lightweight, quick product opportunity assessment is still valuable in that I become much better informed about what this product involves. It is possible that what you learn will change your CEO’s opinion, but more likely it is a good opportunity, and your CEO was right to want to pursue it, but at least now you know what you’re up against if you are to succeed.

 

Product Assumptions – Which one are you making today?

When a team sets out to develop a product, they generate a series of hypotheses. In my experience, good teams are explicit about these hypotheses and test them before they invest too much time into a particular product plan. However, more often than not, I see that development teams are not even aware that these hypotheses exist, instead building their products as if they were fact. The problem with this approach is that rarely does a team get all, if any, of these hypotheses right from the get-go. If they don’t first test them, they run the risk of building a product that nobody wants. Let’s take a look at an example to illustrate how this works.

Explicitly Enumerating Product Assumptions as Hypotheses

I have an idea for a Delhi Metro mobile app. DMRC is the local Metro train that runs with-in NCR regions. Riders include daily commuters and occasional train riders. As a daily commuter, I witness a number of problems experienced by occasional riders. They don’t know how to buy tickets, they don’t know how to pay for parking, they don’t know which platform to stand on. They don’t know how to tell what stop they are at.

I suspect that if DMRC tackled some of these problems, they might convert more of these occasional riders into daily commuters, growing their ridership. I’ve often considered building a DMRC mobile app that addresses some of these usability problems.

The app would walk the occasional train rider through each step of the process of riding the train, starting with where to park, how to buy a ticket, updates on when the next train is coming, updates on where you currently are relative to where you want to get off the train. My goal would be to make it as easy as possible to ride the train.

I know how to do all of these things. I’m observing these problems first hand from past 1 year. Should I just get started and build the app? How do I know that occasional riders will want it?

Let’s take a look at some of my assumptions or hypotheses underlying my app idea.

• H1: Occasional train riders will download a DMRC mobile app before they ride the train.
• H2: The problems that occasional train riders experience are big enough that they will remember to use the app they downloaded earlier to help solve their problems.
• H3: The desire to ride the train is great enough that if occasional train riders had help they would ride the train more frequently.

It’s quite possible that occasional train riders don’t anticipate having problems. If they did, they would probably choose to drive rather than take the train. So H1 could be a big hurdle.

H2 may not be as big of a hurdle. It’s possible that if I did download the app and I run into a problem, the problem itself may act as a trigger to remind me I have the app. But that still needs to be tested. It might be easier for me to just ask somebody nearby. Or I might just give up, something I see people do daily.

With H3, if my goal with the app is to help grow DMRC ridership, then I am assuming that the reason people don’t ride the train more often is because it’s hard. This might be part of the problem. But there are a number of other reasons why occasional riders might not take the train more often – the big one being that it is often slower than driving. Even if people had all the help they needed, they might still choose to drive over taking the train because they simply want to get to their destination sooner.

Now I need to find out the solution for testing these hypothesis, till then cheers!

 

Everything is a Product Management

The basis of the post is this: Everything is a product management problem. Not just the product. Not just features. Not just platforms. Everything you do.

The same techniques and skills you use to manage product development can be applied to your startup, your business plans—and you, yourself.

It’s about compromises and resources and time. It’s about ship dates. It’s about controlling feature creep. It’s about making go/no go decisions. It doesn’t matter whether you’re an engineer, marketing, management, or sales. In the startup world, everything is a product management problem.

With that in mind…

Everything is a product management problem

Now, I’m no expert in product management.

I’ve spent a lot (a lot) of time sitting in product management meetings and listening. My primary contribution to product management meetings?

• Meeting #1: Me: “When are we scheduled to launch? What’s the date?”
• Meeting #2-#999999: Me: “Does that affect the launch date? Is the launch date slipping?”

Yes, vital component. That’s me.

But it’s good. Because when I keep my trap shut, I actually listen, so I’ve managed to pick up a few things here and there.

And here’s where the worm begins to turn.

So, the other day, I’m staring off into space, thinking about product management, and this occurs to me: Everything is a product management problem.

How so? Well, let me outline some of the high points of product management.

• Timeline / Road map / Lifecycle. Every product has one. The really good ones detail the life of the product, from conception through demise. On it, you can see every upgrade, every feature, every release, every date. Everything that will happen to that product. This is the plan. For the entire product. Everything that happens occurs here so that it can be seen in the context of the product life. And every change that is made is reflected here. All the new features, all the slips, all the last minute requests, all the executive force ins. Not only is interesting and vital to managing the process, it’s one hell of a document for the post mortem. And it’s the polar opposite of our next item.
• Trade offs and compromises. This is the product manager’s preeminent skill. Everything in product management is a series of trade offs. When is that resource available to build that functionality? Regardless of when that functionality is built, when do we release it? What does the market want? What does the company want? What do we do to incorporate this last minute requirement? How do we retool based on the usability tests? Everything is a balancing act for the product manager. You can’t do everything at once. And you can’t do everything before launch. It’s a constant game of ready, fire, aim. What is attainable versus what is necessary.
• Resource management. Once locked, loaded, and focused on target, how do we manage the resources at our disposal? Are we going to wedge in some additional functionality while we have engineering cycles? Are we going to bring in outside help to get us through this rough patch? Can we rely on a single engineer to bring everything to fruition? What if that person falls ill during QA? How much do I have to spend to get this done? Can I buy more time? Can I buy more resources? Do we have to build? Can we partner? Can we acquire?
• Translation. The product manager is a Rosetta stone of sorts. Sitting somewhere between the business aspects of having a product and the labor required to bring that product to fruition. In high-tech, as an example, engineers don’t generally want to hear about the business reasons behind feature #479. They want to know the spec and they want to know what technology is at their disposal to create the feature to spec. Conversely, the CEO generally couldn’t really care less if you’ve created an AJAX implementation or used C#. S/he wants to know if the customer will be jumping for joy or throwing up all over it.

So taking those high-level points, shouldn’t we all be product managers for everything we’re doing? Shouldn’t we be product managing our startups? Product managing our investors? Product managing our employees? Product managing our product?

I mean, couldn’t your startup use some product management? A timeline? A life cycle? An attainable list of features and functions to be launched at specific intervals? What does version 3.5 of your startup include? Is it Windows, Mac OS, and Linux compatible? What mobile platforms do you support? Where are your feature/function gaps that could move your startup forward or doom it to inadequacy? What features do you want versus what functions does the business want? What happens when a competitor enters the market?

How’s your startup’s usability?

Think about it. Your startup will be better for it.

Related articles

• Google: What makes someone a great product manager at Google? (umayrjaved.wordpress.com)

 

Facets of Product Management

In this article, I myself will try and understand the role of Product Manager and of Product Marketing Manager:

It Is What You Define It Is!

CTO : This is why he would like to have a role of Product Manager : He wanted someone to document all the features in their product (which had already been created) in one Word document so that they can understand what features were in their product. He also said he didn’t want the PM team to “muck around with defining features or product strategy” because between him and the VP of Engineering, they had it covered.

VP – Engineering : This is why he would like to have a role of Product Manager :- “What is the biggest reason you want to build a product management team?”. He told me that he wanted someone to create UML diagrams of the current product as well as for all the new features that he planned to come up with so that developers could implement them.

What Do Product Managers Do?
While the role of a PM varies widely depending on the company, there are several key responsibilities that product managers usually undertake at a vast majority of successful high-tech companies – based on my research and as well as conversations with friends in the industry. Here is how you can group them:

i.        Market Research:

This refers to the activities of studying a market to understand the customer needs, competitive landscape, and market forces – with the ultimate goal of uncovering opportunities for creating product enhancements as well as new products.

This is done via conversations with customers or potential customers, talking to customer-facing teams such as sales and support, studying reports and articles on the marketplace, test driving competitive products, keeping tabs on customer behavior, and other such activities.

This culminates with the PM preparing a business case, product strategy and/or business requirements document (BRD) detailing how to capitalize on the uncovered opportunities.

ii.        Product Definition and Design:

a) Product Definition refers to the activities of specifying what a product needs to do. This is usually done via what is referred to as Market Requirements Document (MRD) or Product Requirements Document (PRD). This document may include information such as product vision, target market, competitive summary, detailed description of product features, prioritization of features, use cases, system requirements, performance requirements, sales and support requirements, etc.

b) Product Design refers to the activities of specifying the look and feel of the product including the user interface (UI) and the user interaction with the product – covering the whole spectrum of user experience. In larger companies the PM works with UI designers or interaction designers to create this, while in startups the PM may do all of these.

I consider this to be the most valuable among a PM’s activities – so much so that I actually think product manager jobs which don’t include this responsibility are really not product manager jobs at all!

iii.        Project Management:

This refers to the activities of leading cross-functional teams including engineering, QA, UI design, marketing, sales and support to develop and launch the product on-time and on-budget. This may include securing resources, creating project timelines, tracking progress against timeline, identifying critical paths, getting additional resources when needed, and communicating status to the executive team.

In larger companies, Project Managers actually perform most of these activities with the support of PM’s. In very small startups, the PM may be asked to do these by herself. In some companies, the Engineering Lead may do most of these activities as well.

iv.        Evangelizing the Product:

This includes the activities of communicating the product benefits, features and target markets, and in general championing the product to internal teams such as sales, marketing, support and executives. This also includes evangelizing the product to external audience such as press, analysts and customers.

In larger companies, the PM is supported by the Product Marketing, Marketing Communications (MarCom) and/or Press Relations (PR) teams in evangelizing to external audience.

I consider this to be the second most valuable among a PM’s activities – especially evangelizing to the sales & marketing teams, and the executives to create excitement around the product.

v.        Product Marketing:

 

This refers to the activities of outbound messaging – telling the world about the product. This includes creating collateral such as datasheets, brochures, website, flash presentations, press packages, trade shows and more.

In larger companies, the product marketing activities are almost always separated from the PM. They’re instead performed by the Product Marketing Manager. The biggest shortcoming of this arrangement is the resultant inefficiencies in communication and the weakening of outbound messaging.

In some companies the terms ‘Product Management‘ and ‘Product Marketing’ are used synonymously and one person is responsible for all activities. In companies where there are separate ‘Product Management’ and ‘Product Marketing’ groups, the latter group performs all the activities mentioned in this category.

vi.        Product Life Cycle Management:

This refers to the activities of managing a product as it goes through its life cycle from ideation to launch to growth to maturity, and eventually to decline.

This includes tasks such as product positioning, pricing and promotion, product portfolio management, competitive strategy, making build/buy/partner decisions, and identifying and developing partnerships. The PM works with Product Marketing, Business Development and MarCom teams on many of these activities.

There you have it – my attempt at demystifying the role of product management.