Not Signed-In
Which clippings match 'Project Management' keyword pg.1 of 3
18 JUNE 2014

Scrum: iterative and incremental agile software development

"Scrum is a management framework for incremental product development using one or more cross–functional, self–organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. Scrum uses fixed–length iterations, called Sprints, which are typically two weeks or 30 days long. Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration."

(Michael James)

1

2

3

TAGS

agile developmentagile modellingapplication development • close online collaboration • cross-functional teams • development life cycleface-to-face communicationfacing unpredicted challengesflexible management methodology • holistic process • incremental development • incremental product development • iterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)management methodology • Michael James • physical co-location • product development methodology • product development strategy • project managementproject management method • requirements churn • return on investment (ROI)scrum software development processself-organising teamssoftware development method • sprints • whirlpool model

CONTRIBUTOR

Liam Birtles
15 JUNE 2014

Trello: online just-in-time project organisation software

"Trello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what's being worked on, who's working on what, and where something is in a process."

1
2

TAGS

oards • collaboration software • Fog Creek Software • freemium model • just-in-time (JIT)just-in-time analysis • just-in-time production • Kanban • lists • planningproduction processproductivity toolsproject managementproject management toolproject scheduling • project task • project team • scheduling system • software solution • task list • tasks • team management • time management • Trello

CONTRIBUTOR

Simon Perkins
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
22 OCTOBER 2013

Project Management and Business Analysis Guides

"The Project Service Centre (PSC) role within CSU is to establish sound Project Management (PM) principles throughout the organisation. This will provide a means of clearly identifying the true needs of the University and help facilitate those desired outcomes.

To achieve these objectives, the PSC must provide and enhance the methodology for project management and business analysis, including guides and templates. This particular section concentrates on a set of guides which recommends how different processes can be undertaken."

(Charles Sturt University)

TAGS

enefits analysis • brainstormingbusiness analysisbusiness analystbusiness communicationbusiness logicbusiness management • business process modelling • Charles Sturt University • conducting meetings • cost estimatedecision makingdocument analysis • echnical specification • elicitation practices • elicitation process • engineering process • financial analysis • focus group • functional decomposition • gathering requirements • interface analysis • interviewingmodelling and prototyping • needs analysis • PowerPoint lectureproblem-solvingproject managementprototypingquestionnaire • requirements analysis • requirements elicitationrequirements engineeringrequirements gatheringrequirements process • requirements workshop • reverse engineeringrole playingshared practicessoftware engineering • stakeholder interviews • surveysystem requirementsuse casesuser activity data • user observation • workshops

CONTRIBUTOR

Simon Perkins
11 NOVEMBER 2012

Design Guides for Business: Writing a design brief

"A brief is basically a set of instructions that set out what you want your designers to do, along with the objectives and parameters of the design project.

It should make clear what falls within – and outside – the scope of the work. This will help everybody refer back to where they started and make sure that the design work is developing according to your objectives.

It will also help you determine how successful the project has been when you reach the end. ...

Unfortunately, all too often briefs are agreed verbally – but a well–considered brief can act as a general grounding document if the project appears to be heading in the wrong direction, so it's well worth putting something in writing.

And remember, the brief isn't carved in stone; it can be adapted as you go along, as long as it's done in collaboration with everyone involved and the new version is also written down."

(Design Council, UK)

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.