SDLC and Product Management

"NASA spent millions developing a zero gravity pen while Russia used pencils" (apparently a false claim). Regardless of the validity of this statement, many in the software industry use this as a lesson in mindful software development. Lesson is that, not to be order takers, but to be responsible and capable solution providers. In this case… even if the customer has asked for a zero gravity pen, don’t assume that is the best possible solution for customer’s need.


“Product Management” is defined as a central role in IT; for the process of providing appropriate solutions. Product manager is tasked with being the primary contact to customer. Product management is because a problem can be defined in many ways and resolved in many ways. And sometimes, individual business units are not fully equipped to see the problem at an enterprise level or recognize an optimal technical solution for the business need at hand.


Product Manager is supposed to be the interpreter of business vision, need, problem etc. into a viable (cost effective) resolution. Product Manager needs to understand the problem and all its nuances; and if the eventual solution is the best fit from a business perspective. Product Manager is responsible for first documenting the problem and success criteria; and then… when a solution is defined by Architecture, documenting all accepted risks, assumptions, shortcuts taken to provide the solution. This also means that if the ultimate solution does not make business sense, it is the responsibility of the product manager. Somebody needs to take ownership of ultimate delivery value; and that falls on the project manager.


To put this another way, Product manager is somewhat like the lawyer representing a defendant. Lawyer is to understand and interpret chatter from all sides in order to define a course best for the client. Per, Microsoft Solutions Framework (MSF), product management is defined as advocating for customer (representing customer interest in the project); even though Product Management is a role from IT.


In the hypothetical case of the NASA example, NASA should be able to ask the product manager; the business rationale behind the pen/pencil decisions. Everyone likes to comment and offer advice on seemingly unsuccessful projects; everybody has an opinion afterwards. And, we should not assume that the pencil is the better answer; before understanding requirements and business sense behind the decisions; such as many NASA specific long term goals and outer-space specific constraints. Part of product managers job is to anticipate and be ready for incoming issues.
 
 
Some reasons for Product Management role

1. A problem or need can be defined in many different ways.
2. Customer may pose conflicting needs and conflicting expectations.
3. Customer may not have spent enough time to fully understand the problem and scope.
4. Customer may not be able to articulate a technical solution.
5. A good understanding of business domain is critical to establish solution value.
6. Need to discover hidden/all stakeholders and understand motivations.
7. Business needs may change mid course or evolve throughout the project.
8. Translating business needs into technical solution is not trivial.
9. A problem can be resolved in many different ways.
10. Project Constraints (money, people, capabilities, Risks) may limit solution scope.
11. Everyone involved and not will have an opinion that may affect solution definition and eventual customer perception.
12. Overall customer satisfaction and perception should be managed continuously.
13. Someone needs to take ownership of delivering a cost effective solution with business value.
14. Because delivering no solution is better than delivering a bad solution.
15. All above needs to be documented and managed.

It is sometimes difficult to imagine a solution and its effectiveness prior to implementing. This is where a product manager comes in; to help customer navigate through vision, objectives, user-requirements, constraints, risks to a satisfactory resolution. Better you understand customer and need, better you can propose a solution with better ROI and less risk.


Product Manager takes the documented problem and the perceived answer to Architecture to design a technical solution for the need at hand; and Project Manager is wondering if there is money and time to accomplish the solution defined by Architecture. MSF also notes that the conflicting interests between Product-Management, Architecture and Project-Management should be turned into healthy discussions to achieve a sensible and balanced solution for all parties. For an example, product manager may be asking for a perfect solution that resolves all customer issues… while architecture is aiming for a solution that is only based on current capabilities… and project manager is looking to complete the whole this in three weeks.



Product Managers should 

1. Define the problem before defining solutions.
2. Spend time to understand relevant business domain.
3. Not worry if a solution is technically feasible when defining a problem.
4. Talk to other knowledgeable (business architects etc.) parties about the problem being defined.
5. Document business vision, requirements, goals, success criteria and constraints.
6. Get approval for the documented business problem.
7. Represent and defend customer interests... when looking for solutions (with architecture and project management).
8. Own the proposed solution; make sure that the customer will benefit from the end-solution.
9. During building… make sure original plan is being delivered (don’t let builders get creative without approval).
10. Manage customer expectations and satisfaction.

Depending on the size of the project, allocation for product management could be from a partial person for small projects... to multiple people representing feature teams for larger projects. Conflicting role assignment may work for small projects (like one person being product-management, project-management and development), while lager projects suffer from inadequate attention to balancing values of each role. When  the project team is dismantled at end of the project, product-management role may need to continue for various reasons like ongoing question, continuous value realization, enhancements, bug fixing etc.


Because product managers usually get paid from IT budget… in case of conflicts between IT and Business mandates, product managers are sometimes forced to take on IT side of the conflict (even though Product Management is defined as “advocating for customer”). This is more apparent in cases of outsourcing solution definition/delivery to external organizations. Even though a product manager is appointed from the external organization to represent customer, product manager is really representing external interests. This is where the business itself should invest on their own product manager to validate external product manager’s work (product owner (from business) may not have enough technical knowledge).



So... to be practical SDLC

1. In the beginning of a project, assign needed personal for product management role.
2. Ask if product management understands the business domain and responsible for eventual outcome.
3. Ask if product management is representing customer in technical conversations.
4. When the solution/product is delivered at project completion, make sure that someone in IT is assigned the continuing product management roll.

3UNNCNDV3ZVZ

Testing for Quality Software

As the blog title goes… to be Practical SDLC, I will start with a “software quality assurance” topic; that is actionable.

Failed Interview
In a QA-specialist job interview, interviewer has asked a friend of mine to give test cases for a hypothetical simple-calculator; the company want to sell ( with only digits and plus/minus signs).
My friend has talked about building test cases for small numbers, big numbers, zero, negatives etc.

Interviewer has told him that he failed that portion of the interview because… a tester must always ask for initial requirements to build additional test cases needed to satisfy the ultimate goals for the product (in the case of the calculator, if it was meant for childlen... rugged, big buttons, distinct beeps for plus and minus etc.).

So... practical actionable items are

1. When you are asked to build test cases, always ask for original requirements.
2. Involve QA from day one of a project; ask testers to think about (or start creating) ways (test cases/scenarios) to verify requirements (vision, scope, goals, success criteria) stated in early documents.
3. This also means that, do not start building without vision, scope, goals and success-criteria documented (let’s talk Agile later).

Some QA related references for further research
Project Charter [business vision is stated in business language]
Requirement Specifications [to be used as input for later documents] Functional Specification, Logical Design, Physical Design, Interface Specification(s) [output documents based in requirements]
Black box testing [input: Requirements, functional specification, high level design docs. output: Test plans for interface tests, load tests, stress tests, security tests/review, various usability tests like globalization.]
White box testing [input: high level design docs, detail design docs, source code. output: Test plans for internal methods (various code path performance, resource utilization, locking models, loops, conditional statements, boundary checks, security tests etc.)]
Peer review [getting peers to review code at code completion ] Everybody does unit tests, integration tests, functional tests, system tests, performance tests, user acceptance tests etc., we sometimes forget to Install/uninstall, failover, disaster recovery (is service level documented?) tests.
Don’t forget usability tests [MSF defines a user experience role; dedicated to ensure end-user (business, operations, helpdesk etc.) satisfaction.]
Mutation tests [create bugs to see if existing tests can catch created bugs]
V-Model software development [pays special attention to importance of testing]
Maintenance Specifications [documents related to maintenance activities]


QuestionWho is responsible, if a delivered solution is declared useless due to... business having a valueless vision or IT incorrectly interpreting business vision/goals?