Closing on Poorly Contracted Projects

I was once asked to help with a large transformation program at a fortune 500 product development company. They had outsourced several IT security transformation projects to a vendor. The contract was very poorly written, more assumptions than deliverable were listed, the deliverables listed were not measurable and there was too much loose information. The projects which were supposed to take six months each ended up taking three years.

 

I was faced with one of two options, spending dozens of hours sifting through project change requests, meeting minutes and status updates for three years' worth of work, or come up with an agile, fair, and meaningful approach to close on the project. Luckily, I was provided a punch list that a former project manager in the past had felt was all the work items missing. The punch list helped me make the decision to choose the latter option and follow an agile approach to close out on the project. I followed some simple steps;

 

1. Setup weekly punch list calls
2. Defined my role and the objective of the effort
3. Went through the list each week
4. Compared to the original contract
5. Identified any gaps

 

These five steps might seem straight forward, which they are, except when you have two teams, one representing the client always asking for additional items which are mainly operational enhancements and not project deliverables; and another team which is the operational team on the vendor side fulfilling these requests, not realizing that they are also playing a role as the project vendor team. This is the crux of the complexity. It is not that the projects were not closed out, and not in production, they were indeed open projects, but the work delivered is well in production use for years, with new teams on board from both sides and now people are not considering the original baseline or expectations, they are comparing with the day before. It was a continuous bleeding scar for both companies.

 

So the trick in closing these projects in addition to the agile process above was assertiveness, clarity, separation of duties and the ability to act as a mediator and setting a clear measurable deliverable for each open item, with the confidence to act as a business analyst or contract manager specifying the measurable deliverable as needed on the go.

Requirements: Engineering vs. Management

Which is a subset of the other, is the process of requirements management a subset of requirements engineering or the other way around?

To best answer this question lets get back to the basics. What is "engineering" and what is "management".

The term engineering is used to indicate an activity whereby an engineer utilizes findings of sciences to realize solutions which solve problems. To provide an example, a society which has a problem crossing a river asks a civil engineer to realize a solution to this problem. The engineer based on his readings and input from scientists in the fields of chemistry, physics and materials suggests using a steel structure which can withstand corrosion from the environment, and hot summer temperatures as well as extremely low winter temperatures. The engineer performs calculations to detemine bridge loads and how the structure will behave to cross winds and othe environmental elements.

So back to requirements engineering, it is the process used to determine how to best engineer (recognize, analyze and synthesis) a requirement.

Generally speaking management is defined as the activity of controlling, organizing, planning, and directing. It can be argued that planning and analysis do overlap and hence both requirements engineering and management overlap to some degree, and I would agree with this. However requirements management has a much broader scope than engineering, requirements management plans, organizes, controls and directs the processes related to requirements "handling", this handling includes engineering, development, maintenance and obsolecence. Changes to requirements are considered part of requirements maintenance which is part of reqs mgmt.

Requirements management involves developing a database to store requirements, a report from this database could be the RTVM, a list of configurable items (CIs), requirements management could also include tracing requirements to business requirements upward and to test and verification results downwards, it also ensures that the synthesis process in requirements engineering is sound and consistent and traceable to project work packages in the work breakdown structure (WBS) and eventually the statement of work (SOW). It involves establishing requirements baselines, negotiation with stake-holders and prioritization of requirements and changes.

We should not assume requirements management to be a phase in the system life-cycle, but rather a continuous process overseeing all the phases of the system, nor is it a subset of requirements engineering but rather a superset of the various system phases. This is illustrated in the chart below.

A few papers related to requirements management are listed,

[1] Ian Somerville and Pete Sawyer, "Viewpoints: Principles, Problems and a Practical Approach to Requirements Engineering", Lancaster University, 1997.

[2] James Martin, "A Process for Requirements Definition and Architecture Definition", Texas Instruments.

[3] James Martin, "Systems Engineering Guidebook: A Process for Developing Systems and Products", CRC Press, 1997.

Hello I am Your Systems Engineer. How Can I Serve You?

The last thing a systems engineer wants to ask a client during a requirements gathering process or JAD session is "So what features or capabilities do you need?". If the client knows what they need, there is no reason to hire a systems engineer.... right?

So how can an SE find out what a client needs? Asking for what the problems are is probably the first questions an SE needs to bring up. Identifying the problems, the root-cause for these problems, the severity, history and impact are the questions the clients need to hear. Clients understand very well their problems, they usually have a slight idea or thought on potential solutions, and in many cases don't. But all clients will know what their problems are, or at least will be able to explain the manifestations of a problem.

New Product Requirements

There are various sources for requirements gathering for a product or service. Obviously the most important source is the customer who will be using the product or service.

Another valuable source is the environment in which the product and customer will both be surrounded by. A list of the most relevant environments that a product manager or systems engineer should take a look at are:

1. Technological Environment
Presence of new inventions, innovation, methods, processes, materials to achieve new tasks or perform older one better, etc...

2. Economic Environment
The cyclical changes in local and global economies, inflation (prices rising/lower purchase power), recession (trade down/employment down), unemployment, depression (panic), recovery, prosperity (employment up/trade up), off-shoring, debt/savings levels, income distribution

3. Competitive Environment
The landscape of competing (monopoly, perfect, oligopoly, monopolistic), competitors status, etc...

4. Sociological Environment
Cultures, changes in industries, religion, subcultures (teens, seniors), crime rates, etc...

5. Political-Legal Environment
Legislation, regulations, PACs, wars, etc...

6. Demographic Environment
Age, gender, customs, location of residence, etc...

7. Natural Environment
Natural resources, raw materials, pollution, etc...

Astute system engineers should research all these environments. The level of research might differ from on environment area to another depending on the product/service being developed. In some cases other environments might be considered and some of those listed above ignored.

Needs - Wants - Demands

Just like a smart marketer, an astute systems engineer knows the difference between the three:

Needs - are basic requirements, like eating and going to the bathroom

Wants - are needs that become requirements for fulfilling basic needs, for example people want education to find a job, to make money to buy food to meet the basic need. Wants are shaped by the environment the client is in.

Demands are wants for specific products coupled with an ability to pay.

Marketers do not create needs. Needs already exist. People need to eat, move, dress and learn. Marketers only promote the idea that a burger, car, Jeans and private school will satisfy the client's needs, by highlighting the benefits the client will achieve using the product.

Is that What Your Client Really Needs?

Customers need a lot of things, in most cases they do not realize what they need. However we can usually group a customer's need into these 5 areas:

1. A stated need - I need a box of cereal
2. Real need - I need something healthy to eat quickly in the morning
3. Unstated need - I expect to find the cereal box easily and quickly
4. Delight need - If the cereal will allow me to add fresh raisens and banannas all the better
5. Secret need - Got to show off infront of my wife and tell her I got it on sale 3 for price of 1

An experienced system engineer can sense and identify the needs 2 - 5, and bring them out to the client for verification -- this is where value is added.

The 4 Ps of Marketing and 13 Aspects of a Good Requirement

Just as marketing has 4 Ps: Product, Promotion, Place and Price

Requirements have 13 attributes:
1. Describe what and not how
2. Atomic
3. Unique
4. Documented
5. Identifies owner
6. Traceable
7. Necessary
8. Complete
9. Unambiguous
10. Identifies applicable states
11. Testable and quantitative
12. Not a constraint
13. Not a goal

Rule of thumb: A requirement should be satisfied by only 1 design component, it not feasible then it should be broken down further.