Collecting Project Requirements
By Marc Derendinger, Northwest University
It often helps to think of this process as finding what is needed to satisfy the stakeholders and creating a document to reflect this understanding. These requirements become the basis for your Work Breakdown Structure, so need to be detailed enough for accurate measurement once the project is underway.
Since this process is defining your stakeholder’s expectations, it follows that an input is your stakeholder register. In addition to containing the stakeholder’s information, it would also be beneficial to detail their influence, interest and requirements. The other input for this process is the project charter. The high-level view of the project found in your charter can be thought of as a baseline to form your requirements onto. There are a variety of tools you can use to collect and document these requirements.
Interviews can be effective in getting detailed needs for a product from subject matter experts. Read the Complete Article
Why Projects Succeed: Minimize Scope and Requirements
By Roger Kastner
Whether measured by schedule and budget, scope attainment, stakeholder expectation management, end user adoption, or market success, leading a project to a successful conclusion is challenging. What might be surprising to know is sometimes the challenges are self-inflicted, and one of the leading causes of self-inflicted project failure is attempting to do too much.
The Standish Group, a technology research and consulting firm, studies IT projects and annually produces their “chaos” report which includes statistics on rates of project success, as defined as being on-time and on-budget. In 2009, the Standish Group found that 32% of the IT projects they surveyed were “successful” as defined by on-time and on-scope. Additionally, since some projects successfully hit their on-budget and on-schedule targets but fail to hit the mark with consumers or are not adopted by end-users, the Standish Group might have these in the win/success column however they will never be called a success by stakeholders because they did not deliver on ROI. Read the Complete Article
Requirements Gathering in Project Management: Not Enough If Not Priortized and Ranked
By Gratien Gasaba
“If you don’t know where you are going no road will take you there”.
To ensure that one is on the right road one needs to know where this road goes. But it serves for nothing if you don’t know where you are going. Assume you are in a bus station. You may be informed that bus number 1 will take the road to place A, bus number 2 to place B, bus number 3 to place C, etc. What criteria do you use to choose a right bus and to ensure you don’t get lost? The necessary and sufficient criterion is to know where you want to go. In the above illustrative particular case, if you want to go to the Place C, you will take the bus number 3 and exclude from your choice all other buses. Read the Complete Article
Deliverable Map Planning
By Esther Derby
I spent two days last week facilitating a planning session for a software project. I was working with a team from a functional organization with a pretty heavy phase-gate process, and a waterfall way of building. The team was fininsh their “definition” stage, and planning for a 3-month construction and test phase.
Most of their planning has been driven by their scheduling tool and senior managers’ desire for a sense of comfort and control, which pushes them towards high-level Gantt charts. (One of the sub-project managers came in saying that he already had his plan: it showed five (5) activities with durations in months.)
Well, that may be comforting to executives, but its useless for managing a project.
So for our planning workshop, we mapped deliverables.
Here’s why I pushed towards deliverables, rather than tasks:
Read the Complete Article
Sales Process Meets Project Management
By Mike Cunningham
The essential characteristic of most sales situations is that the supplier is keen to sell and is in competition situation with other vendors. Conversely, the customer has a choice of vendor and is seeking the best capability on the most favorable terms. All the time the sales team will be under pressure to offer the best price and delivery time. The vendor is keen to win the business and not do anything to put that at risk. Equally the customer is keen to secure the best deal. In this situation there may be negotiated changes in pricing, and undocumented promises and assumptions that introduce delivery risk and latent issues. For example:
Read the Complete Article
- During commercial negotiations project pricing may be reduced without clear and fully justified reductions in scope.
- The timeline is invalidated due to changes in scope, budget or start date.
- Risks are overlooked and not sufficiently reflected in contingency
- Risks are not all understood by vendor management nor customer management.
On Customer Participation in Agile Projects
By Andy Hayward
Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:
“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”
This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:
“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”
I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto:
Agile requires consistent and constant collaboration between the development staff and the customer, and in my experience, veiled threats and extortion do not foster teamwork. Read the Complete Article
Define the Content and Format Standards for Each Product To Be Delivered
By Richard Morreale
This is the third installment in a series of articles about a 9-Step Structured Project Planning. Today I’m going to write, in as much detail as possible, the content and format standards for each of the Products to be delivered during the project.
One of the big things that I stress when I’m running a project or teaching a project management course is to ‘know what you are supposed to deliver before you start working on delivering it’. What I’m talking about here is that no matter what you are having to deliver, whether it is an entire system, a project or a document the principle remains the same – ‘know what you are supposed to deliver before you start working on delivering it’.. If you know what you have to deliver in terms of what the Product will look like before you start, you will have a much better chance of defining and organizing the work to deliver it. Read the Complete Article
6 Steps to Defining IT Project Requirements
By Kathlika Thomas
We all know that defining IT project requirements is a crucial task when initiating new projects. But did you know that Standish Group’s CHAOS Report shows that a clear statement of requirements is one of the top three reasons for project success? Since it is clear that defining requirements is one of the top PM best practices, we have compiled a series of steps that every project team should follow in order to get on the track to success.
Read the Complete Article
- Business and Functional Requirements. The first step is for the IT project team and end users to define and document all of the business and functional requirements of the project. This process begins with a requirements document. This document details all business and functional requirements of the project. It details the “what” of the project.
Design Requirements. Next, the team and users define the design requirements and add them to the requirements document.
It’s Not A Change Request, It’s A Missed Requirement
By Kerry Wills
My least favorite conversation to have on a project (well, second to the “we’re not going to meet our date” conversation) is the scope conversation. This is the arm-wrestling match over scope elements which business describes as “must haves that should have been part of requirements” and the IT team describes as “not included in the requirements (or estimates).” The conversation usually goes back and forth and results in lots of blaming (see my article on blame)…you didn’t tell me…well I thought I did….we didn’t include it in the plan…but that’s what I meant….and on and on.
The way I have historically tackled these types of things is to focus on the facts and take the conversation away from blame. I tell the business partners that regardless of what should have been in vs what really got documented, the net result is that the item in discussion is not included in the estimates. Read the Complete Article
The 8 Dimensions of Project Management
By Tomer Sagi
I’ve been thinking about this concept for a while now and decided to put it together in a diagram and see if it works.
I tend to see Project Management go beyond the standard triangle of constraints (Time, Cost, Scope while controlling Quality).
I wanted to include the Needs and Requirements to the mix in addition to the deliverables and value as outputs. Naturally I believe they are all linked together to start, control and complete a project.
I think project management is definitive process with definitive inputs and outputs and in the middle we will need to control certain aspects (dimensions) in order to achieve the desired outputs. Therefore he’s my proposition:
Figure 1: The Project Management Octagon
I believe the Project’s input is made out of Needs / Wants and Objectives / Requirements.
Read the Complete Article