Not Signed-In
Which clippings match 'Project Deliverables' keyword pg.1 of 1
26 JANUARY 2014

MoSCoW Analysis: a project requirements prioritisation technique

"MoSCoW analysis divides requirements into four categories: Must, Should, Could, and Won't. It is most applicable for software development or timeboxed delivery efforts, as it focuses on determining which requirements can be implemented given specified time or resource constraints. Category descriptions are as follows:

Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Should: Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

Could: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

Won't: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future."

(Kevin Brennan, 2009, p.165)

Kevin Brennan (2009). "A Guide to the Business Analysis Body of Knowledge". International Institute of Business Analysis. ISBN 978–0–9811292–1–1.

TAGS

building in measuresbusiness analysis • business requirements • clear project objectives • could • design requirements • importance • International Institute of Business Analysis • management methodmanagement methodologymanagement technique • MoSCoW analysis • MoSCoW method • MoSCoW prioritisation • must • organisational process • organisational technique • prioritisationprioritisation analysisprioritisation techniqueproject definitionproject deliverables • project delivery • project goalsproject managementproject management methodproject objectivesproject requirementsquantifiable definitionsrequirements gatheringrequirements prioritisation • should • software development methodtime management • wont

CONTRIBUTOR

Simon Perkins
02 JANUARY 2013

Facing ambiguity differently across design, business and technology

"team[s] of students of mixed disciplines worked together to understand and map a problem–space (identified by the client). They then defined a solution–space before focussing on a particular opportunity outcome. The range of projects included incremental innovation opportunities represented by the Lego and Hasbro projects through radical Philips work to truly disruptive work with Unilever. The studies confirmed stereotypical view points of how different disciplines may behave. They showed that design students were more (but not completely) comfortable with the ambiguous aspects associated with 'phase zero' problem–space exploration and early stage idea generation. They would only commit to a solution when time pressures dictated that this was essential in order to complete the project deliverables on time and they were happy to experiment with, and develop, new methods without a clear objective in mind. In contrast, the business students were uncomfortable with this ambiguity and were more readily able to come to terms with incremental innovation projects where a systematic approach could be directly linked to an end goal. The technologists, were more comfortable with the notion of the ambiguous approach leading to more radical innovation, but needed to wrap this in an analytical process that grounded experimentation. Meanwhile, the designers were unclear and unprepared to be precise when it came to committing to a business model. "

(Mark Bailey, 2010, p.42)

Bailey, M. (2010). "Working at the Edges". Networks, Art Design Media Subject Centre (ADM–HEA). Autumn 2010.

1

TAGS

2007ADM-HEAambiguityambiguity and uncertainty • ambiguous approach • analytical processapproaches to ambiguitybusinessbusiness modelclear objectivesclient needscollaboration • core competency • Cox Reviewdecision making • design outcome • design teamsdesign thinkingdisciplinary culturesdisciplinary knowledge • disruptive work • Dorothy Leonard-Barton • end goal • grounded experimentation • Hasbro • idea generationincremental innovationinnovation practice skillsinterdisciplinarityinterpretive perspective • learning cultures • LEGO • multidisciplinary design • multidisciplinary teamsNorthumbria Universityopen-ended process • pedagogical cultures • phase zero • Philips Researchproblem-solvingproblem-solving • problem-space • project deliverablesproject teamsradical innovationrequirements gatheringsolution-space • sub-disciplinary specialisation • systematic approach • T-shaped individuals • T-shaped people • T-shaped skillsthinking stylesUnileverworking methodsworking practices

CONTRIBUTOR

Simon Perkins
09 SEPTEMBER 2011

Prioritisation technique for defining project deliverables

"For the most part, I generally advocate a three level rating system for software requirements: mandatory, desirable, and optional. The mandatory requirements cannot be sacrificed, desirable requirements are important but could be sacrificed if necessary to meet schedule or budgetary concerns. Optional requirements are ones which may not be developed, simply due to the fact that they have been rated as being 'nice to have'."

(Paul Seibert, 28 July 2011, Hub Tech Insider)

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.