Requirements

I haven't been interviewed in a podcast before, so I found this unscripted piece to be an interesting experience, one I might do again. You have to think on your feet, interpret the questions, draw on your experience, and try not to stumble over your words. Very challenging!

As the well known saying goes: "When you fail to plan, you plan to fail!". This may seem to be in juxtaposition with the Eisenhower saying "The plan is nothing; Planning is everything!" (both quotes paraphrased), but not when you give it a little thought.

Not having a plan will always be a disaster. Expecting that the plan you create will never change is also inviting calamity. And creating a plan without the collaboration of those who commissioned the project and those who will deliver it is also guaranteed to make your project end (if it ever does and is not cancelled) in a bad space. This is the "Planning is everything" part.

So what sort of planning should you do?

Those of us from the old school often like to take a predictive approach, while those of us from the "new" school may prefer an adaptive approach. Although, as a good friend of mine recently pointed out, "Agile has been around so long now, one probably has to consider it old school!". And that is food for thought. 

Using the right tool for the job, or as Scott Ambler or Mark Lines might say per Disciplined Agile, finding your WoW (Way of Working) is what is important. 

But in the end, whether you deliver using predictive, adaptive, or something in between, the important thing to remember is that what you are delivering has to fit into the organization's strategic DNA. Hopefully in your organization projects that land at your feet do so because the executive team has decided on the portfolio of programs and projects and authorized only those to move forward, heading rogue projects off at the pass.

I hope you enjoy this seat of my pants podcast with Trina L. Martin in her podcast entitled "Trina Talk". 

https://trinalmartin.com/podcast/trinatalk-episode140/

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?

PMI's Pulse of the Profession's recent report on Requirements Management by Dave Bieg (see pmi.org) tells us that "47% of unsuccessful projects fail to meet goals due to poor requirements management".  How do your failed projects line up with this statistic?  Oh, I see - you don't have any failed projects.  Well... that's okay.  I'm sure we all wish you future success on all your projects and we'll move on to those of us who live in the real world. ;)

Projects are complex organizational units that set out to accomplish specific goals in a defined period of time with defined resources.  The clear part of that statement revolves around time and money.  A bucket of money and some start and end dates we can easily understand. Non-financial resources like people maybe are a little more hazy.  But what about that blurry word "goals"?  Sure - we can all understand it at some level, especially during the honeymoon phase of project start up when it tends to be a few sentences in a project charter.  But when it gets down to the nitty gritty, lofty goals translate into detailed requirements that have to be collected, recorded, confirmed, managed and satisfied. 

This is a large topic.  Reams of material have been written just on conducting effective interviews and workshops;  body language; communicating; interpersonal interaction; preparing, sending and analyzing surveys; correlating results and achieving agreement or at least consensus.  And that's only a part of requirements collection, never mind deciding when requirements should be defined, how they should be recorded, achieving confirmation; managing changes to them after the fact as business/organizational needs change and being sure that your project satisfies all of the requirements that were stated in the first place, if that is your mandate depending on the type of project your are running. More complex topics, indeed. 

So - these are some of the problems with which we wrestle on a daily basis as we drive our projects toward the elusive goal of meeting requirements to our clients' satisfaction.  Are there solutions that might help?  Of course there are!  Keep an eye on this space for more beyond this initial little teaser.