Discussions about expectations and requirements tend to focus too narrowly on the relationship with the customer. Expectations come from a much broader group, however.
On a tangent: We do not manage customers. We manage their expectations. Managing customers is just a little too proactive.
Stakeholders include not only the customer, but also management, regulators, subcontractors, and the various departments within the performing organization. Figuratively and to varying degrees, everybody involved is a customer. Expectations, therefore, fall into categories that vary from documented requirements and undocumented management decisions down to bad ideas.
For example, management expects the project to stay within 5% of a given budget. Although management's expectation is not a requirement, it bears just as much force.
Other stakeholder expectations might become product or project requirements during requirements decomposition. For example, -ilities Engineering may identify environmental or safety expectations that the systems engineer will record as requirements.
At an intermediate level, expectations might include awards, schedule needs, training, or internal deliveries of work products or tools that people need in order to do their jobs -- all things transparent to the Buyer.
On the other hand, Marketing may want gold plating that, since they went around the systems engineer, falls to the project manager to reject.
Everybody has expectations. Expectations carry varying degrees of force, but only those that define binding project success in the eyes of the Buyer constitute requirements.
Those in LinkedIn's INCOSE group can read a running discussion about the topic.
------------------
IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e
On a tangent: We do not manage customers. We manage their expectations. Managing customers is just a little too proactive.
Stakeholders include not only the customer, but also management, regulators, subcontractors, and the various departments within the performing organization. Figuratively and to varying degrees, everybody involved is a customer. Expectations, therefore, fall into categories that vary from documented requirements and undocumented management decisions down to bad ideas.
For example, management expects the project to stay within 5% of a given budget. Although management's expectation is not a requirement, it bears just as much force.
Other stakeholder expectations might become product or project requirements during requirements decomposition. For example, -ilities Engineering may identify environmental or safety expectations that the systems engineer will record as requirements.
At an intermediate level, expectations might include awards, schedule needs, training, or internal deliveries of work products or tools that people need in order to do their jobs -- all things transparent to the Buyer.
On the other hand, Marketing may want gold plating that, since they went around the systems engineer, falls to the project manager to reject.
Everybody has expectations. Expectations carry varying degrees of force, but only those that define binding project success in the eyes of the Buyer constitute requirements.
Those in LinkedIn's INCOSE group can read a running discussion about the topic.
------------------
IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e
Posts
No comments:
Post a Comment