Requirements

by
Effective requirements collection, management and traceability plus smart PM practices equals project success.

About this Blog

RSS

Recent Posts

Caution: Agile Surface May be Hot

Organizational Change Management: The Most Critical Requirement of All!

Rethink Requirements: The Natural Language Processing Approach

Quality - Consider it in all Knowledge Areas!

Don't get COT[s] by your package!

Everything is a Project, and Every Project Has Requirements

Did you ever have trouble meeting a goal or deadline, or manage to get something done on time, but it was, well… shall we say less than desirable quality? Ask yourself - did you know what you had to produce every step of the way to be successful? Did you know what success should look like? Maybe it was as simple as doing some maintenance around your house, or planning your family vacation. Or maybe it was something as complex as implementing new processes to meet strategic goals at your company.

When you boil it all down to the essentials, anything that you want to do that is not an ongoing operation, anything that has a defined start and end and a desired result, is a project, or can at least be treated as one. Can you relate it to a goal? Can you describe what needs to be produced each step of the way? Have you identified which person or other resource (like a shovel or a drill, or some materials) will be needed for each one? If you've been nodding your head up and down while reading this paragraph and it's not a result of falling asleep, chances are pretty good you are dealing with a project.

So what isn't a project? Officially, anything that is an ongoing operation is not. But, what if you bound an ongoing operation with start and end dates that reflect the fiscal year, or the calendar month and list the what is required to be delivered in that timeframe? Is it then a project? There is a body of thought that would say yes, and that in fact an operation could perhaps be managed more effectively if those involved in it had clearer deliverables, activities and timelines to follow.

If you do want to treat something as a project, what is a simple way to go about it? Try following the steps below.

Charter the project - Define the reason you are doing this in the first place – the “business” reason, or the personal reason, the main objectives and generally who will need to be involved. Make sure everyone understands this and is willing to do what needs to be done and define what the end game looks like – what will be in place to gain agreement that the project is finished?

Make the plan - Define the requirements and what needs to be produced (the “deliverables”) as well as the activities required to produce each item. Consider the sequence of deliverables, what needs to be produced when, and for each deliverable, the sequence of the activities required to produce it. Consider who will decide whether a quality deliverable has been produced. Define who will execute each activity and make sure you have the required resources for each one (people, equipment, materials, and so on). Consider the cost of people and materials to create an expected cost, or project budget.

Start the project and work to the plan. Periodically take time to consider how you are doing according to plan and adjust it if necessary. Engage those who will decide whether a quality product has been produced. Let everyone on the project and other stakeholders know how things are going, including changes to the plan caused by changing requirements. Will you do more, or maybe even less? Has the timeline and budget been adjusted appropriately to account for this?

Finish the project. Go back full circle. Did you accomplish what you set out to accomplish? Have you reached the goals and does everyone agree the project has delivered on the requirements you collected from the project's stakeholders? Did you learn anything that will help you perform better next time? Did you record it? Did you deliver everything on time, within budget and, more to the point, did it or does it deliver the expected value?

It doesn't matter what you are doing, if you follow simple steps like these to give some forethought up front, plan the work based on solid requirements, then work the plan, you stand a much greater chance of being successful.

Would you agree?

Posted on: October 02, 2014 12:11 PM | Permalink | Comments (0)

WBS - breaking down tasks? Or breaking down deliverables?

There appears to be a bit of split in the use of terminology in defining the scope of a project through the creation of the Work Breakdown Structure.  Some seem to take an activities-based view, as evidenced by the template on this site called Project Work Breakdown Structure Guidelines, while others seem to take a deliverables-based approach, as found in PMI's Guidleine to the Project Management Body of Knowledge, which says that creating a WBS is the process of  "... subdividing project deliverables and project work into smaller, more manageable components".  Still others take a hap-hazard approach - don't worry - we won't talk about that here. 

I have long held that a deliverables-based approach to project planning, executing and, most importantly, progress tracking and reporting is key to creating a mindset on a project that focuses not on what you have done (the "activity"), but on what you have produced (the "deliverable").  Have you seen status reports that focus on activities done last period, and activities planned for next period?  Are they effective?  How about status reports that delve into what was produced last period and what is planned to be produced next period?  See the difference?  One pulls you down into the whirlpool of things people did, often with no relation to why they did these things and what they hoped to accomplish. The other is much more concrete - what you produced in relation to the project WBS.  You can even get very black and white about these things using the done/not done approach - a given deliverable is done, or it is not done - 0% Complete or 100% Complete.  Of course, this doesn't work very well with ill-formed project schedules where a  deliverable can consume many months or even years of effort.  But if deliverables are concise, well defined and restricted to maximum effort levels, it works very well.  Or you can consider breaking large deliverables into work products, the "done/not done" of which determine an overall %Complete, and track your deliverables that way.

If you consider a deliverable to be the output of an activity, why not flip it around and relegate activities to those things you must do to produce a deliverable?  You can structure your project schedule around deliverables, and you can measure your progress based on the deliverables you have produced, or the portion of a deliverable you have produced.  This ties in very nicely to Earned Value Management, but that is another topic.

How do you define the scope of your project?  Are you an Activities-based or a Deliverables-based thinker?  Do you measure progress based on what your team did for a period of time?  Or on what they produced?

Posted on: September 17, 2014 09:15 AM | Permalink | Comments (1)
ADVERTISEMENTS

"Life is what happens to us while we're making other plans."

- John Lennon

ADVERTISEMENT

Sponsors