Requirements

It might seem a little odd to write a blog item about a webinar on this same web site, but I thought those who don't know about it might gain by watching it. Besides, I'm proud that a colleague, Jordan Kyriakidis, from my home town, Halifax, Nova Scotia, and his firm, QRA Corp, have been so innovative in coming up with such a fascinating automated method of assessing requirements.

That it is being used in the aerospace industry is just "icing on the cake"!

According to PMI’s Pulse of the Profession, “When projects do not meet their original goals and project objectives, inaccurate business analysis/requirements management is cited as the primary cause 47% of the time.” And the increasing scale and complexity of projects is making it extremely difficult to assess and verify the project requirements. As a result - many critical errors in project and systems development arise in the initial concept & design stages. 

The webinar focuses on how harnessing automated computational tools utilizing Natural Language Processing can help project managers ensure their requirements are consistently clear to ensure poorly written requirements do not infiltrate later project stages. Why not reduce stress and increase the probability of project success?

Take and hour or so to listen to Jordan Kyriakidis (and me to some extent). Judging by all the positive comments already recorded there, you'll be glad you did!

Here's a link to the webinar:

https://www.projectmanagement.com/videos/337012/Rethink-Requirements---The-Natural-Language-Processing-Approach 

Enjoy!

Early in my career I was fortunate to have a mentor who was very data driven.  He believed that data in its purest form would help describe the processes that you might want to implement in a system, but that process analysis alone would not properly define the data and in fact, might very well define it improperly due to the usual insular aspect of looking at some processes and not all, of necessity given scope and budgets.

When I think about this at a high level in terms of typical data entities and processes, I have to believe that the metrics would support such a conclusion.  If we look at any particular organization, the number of processes operating on the same, similar or related data will be very high, yet the number of entity types the organization deals with will be very low in comparison.

So let's look at a very simple example, a basic course registration system.  Here are the entity types we'll deal with:

1. Student
2. Course

Here are some business rules around the data:

• A student can register for up to eight courses.
• A course can have up to one hundred students.
• Students can see who else has registered for a course

From this simple example, I conclude that we have at least the following potential processes:

1. Registering for a course
2. Seeing details like who is teaching a course, costs of courses
3. Listing who is also registered for a specific course
4. Updating or deleting a course registration
5. Finding out if I am allowed to delete a course registration
6. Finding out the rules and timelines around course registration
7. Withdrawing from a course after I have already started attending it
8. Listing all courses I as a student am registered for
9. Displaying detailed information about a course I am registered for, or courses for which I am not registered
10. Plotting course schedules on a calendar so I can generate an agenda for myself
11. Show ratings for each course
12. Show ratings for each instructor
13. Show the marks I have achieved for each course by term and final
14. Show a history of my marks in the timeframe I select
15. Show a graph of how my performance has changed over time
16. Show a graph of how instructor performance has changed over time for selected courses or for all courses he/she teaches
17. Update course information - new courses, remove or archive courses, update who is teaching a course
18. Update student information - new students, remove or archive student information, update student demographic, biographical information and other information 

.... and so on ... and so on... and so on...

All of the processes I listed come directly from the two entities, student and course, along with the attributes each has and the relationships they have, one with the other.  I am sure with a little extra thought, the list could be doubled.  I am also sure that some of the processes listed have nothing to do with a student registration system, and more to do with other systems, and so could serve to put some rope around both the data (and its attributes) and the processes to be able to plan multiple projects as part of a program.

Furthermore, since we all know there is a many-to-many relationship between Courses and Students, we are probably missing an Entity Type - one that is fairly obvious anyway - something called "Course Registrations" which becomes a one-to-many relationship with each "Kernel" entity type, resolving the many-to-many relationship by adding the "Associative" entity type.  And we won't even get into the difference between registrations and transcripts, whether things like marks even belong in this model, etc.

I obviously invented  a lot of the processes I listed, and they would likely be very different if I actually had stakeholders to help me along (or would they?).  It may reveal new business rules, such as those student registration privacy or restrictions on instructor performance data, or the absence of processes, such as being able to label other students who are your friends, and seeing which courses they have registered for. 

A very simple example, of course, but from two entities (which eventually became three), I was able to derive at least 18 processes (some actually have multiple processes per line), and I did that as quickly as I could type.  Confirmation with the stakeholder would take much longer, of course.

Trying to create a long list of processes and then deriving the data from them, rather than letting the data drive the derivation of processes, is, I feel, much more complex, time consuming and subject to errors and omissions.

What do you think?  Are you process driven, or data driven?  Were you one and became another at some point in time? 

Before you answer, remember the CRUD (or CUDDL) I mentioned in a previous post.  Don't know what that is?  Look up "Of CRUDs and CUDDLs"  :)

People often ponder whether requirements for an IT project should already be in place before a project begins, whether they should be detailed at the front end of a project, or whether they should be refined as the project progresses.  The answer is not simple, and has a lot to do with the sort of project you are running.

We would all likely agree that no project can even be chartered without some level of requirements being in place - high level business requirements at the very least.  But it is a rare project that will kick off to the resounding thump of a multi-hundred page business requirements document. Most waterfall-type projects have the creation of the BRD as an early step in the project. Most Agile projects will have high level requirements, often in the form of user stories.  And then there is everything in between.

But there's the rub.  What apporach and methods are being used on your project?  Is it waterfall?  Is it one of the Agile approaches?  Can requirements change while the project is in motion?  Might such changes alter the direction of the project?

I would hypothesize that requirements can and do change on any project, regardless of the project methods being used.  Remember the old requiremernts freeze?  "You must sign here, and we will build what you have asked for.  No changes wiil be permitted from now until project end."  Seems almost hilarious now, doesn't it?  The only freeze that would really be in effect is the one that freezes you out of any more work with that client.

So - still we are left with question, "When do requirements need to be completed?". The question itself might be a tad banal. Before we design, before we build, before we test... requirements must be clear.  Do we need a 50 pound signed off document early on?  Maybe... if we are designing and building software to run a space shuttle.  But do we need it if we are only configuring an ERP package?  Or designing a web site?  Or might we need only story elaboration a bit at a time when we have a fully engaged and knowledgeable Product Owner?

As with most questions in this field the "It depends." answer pops to mind.  It depends on so many factors, including contract types, that the answer will shift like the sand dunes on the Sahara.  

It's getting cold in here. Must be those frozen requirements. 

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.