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!

Caution: Agile Surface May be Hot

Most people are familiar with the Agile Manifesto and its Principles developed in 2001 by seventeen people engaged in the IT (software) industry. Requirements take the form of a Vision Statement, Epics, Features and User Stories. Agile is much loved by those who like simplicity (does that include you?), high user involvement, high visibility of work to be done and work in progress, continuous team collaboration, self-managed teams, minimal documentation, face to face communication and very fast turnaround of deliverables in pre-planned, fixed iterations, creating a project cadence that raises expectations for frequent showcasing of completed work.

You may concur that sixteen years is a very long time in the software industry. I suspect Agile approaches are already baked into many methods. There has been talk and action for a few years now to make Agile scalable to deal with large projects, and hybrid methodologies have appeared that take advantage of the best of Agile and the best of traditional and iterative approaches. I believe there is wisdom in this thinking - something about not throwing out the baby with the bath water.

But Agile was clearly meant for software projects. Can it be used in non-IT projects?

A recent rather unscientific poll I added here seems to prove that one of the Agile frameworks, Scrum, is sufficiently pliable that it can be used outside the software industry. About 1/3 of the respondents (OK - only 21 responded, but you can change that), said they had used it on non-IT projects already and another third said they were planning to do so.  And there are plenty of industry posts about this. One of which I am particularly fond is by InfoQ, where they highlight some of the challenges with using Scrum on non-IT projects and provide some clues about how to convert from technical software terms to business terms.

I believe any project can benefit from Scrum methods. Who would not want to reap the benefits of high visibility of work to be done, progress being made, frequent communication, an engaged team and client, and work being presented in weeks instead of months or years? Wouldn't everyone want work to be broken down into chewable chunks when it is possible to do so? Remember what our friend Albert said: "If you can't explain it simply, you don't understand it well enough."

Maybe it is time to create an Agile Manifesto for non-IT business projects. What might it look like? I'll go out on a limb here to take a stab at it:

  • Individuals and interactions over complicated methods and software tools
  • Completed deliverables over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Okay - so what changed? Not a lot, really. I changed "processes" to "complicated methods" and "tools" to "software tools" in the first line; "software" to "deliverables" in the second line; and I didn't change the last two at all.

I chose the word deliverables since it is generic and could represent a process, a document, a change in the thinking of a group of people, a new product line - you get it - a business-focused item.

So we might think much of the change would be in the Agile Principles. As they say, the devil is in the detail, which is what the principles start to address. Let's take a shot at modifying those to be more business-focused and less software-focused:

  • Our highest priority is to satisfy the customer through early and continuous delivery of usable deliverables.
  • Welcome changing requirements, even late in deliverable development. Agile processes harness change for the customer's competitive advantage.
  • Produce deliverables frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people, subject matter experts and deliverable-producers must work together daily throughout the project.
  • Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.
  • Credible and usable deliverables are the primary measure of progress.
  • Agile processes promote a sustainable pace. The business people and the team should be able to maintain a constant pace indefinitely.
  • Continuous attention to excellence and good deliverable design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best work emerges from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Once again, not a lot has changed. Software becomes deliverables and some of the more technical terms are converted to more business-friendly terms.

Have you used Scrum on non-IT projects? How did it work for you? Did your business users embrace it? Was the high visibility too much for them? Did the team manage themselves? How was the business user interaction? And perhaps most importantly, were business requirements satisfied?

Weigh in with your thoughts!

Posted on: May 25, 2017 10:53 AM | Permalink | Comments (11)

Organizational Change Management: The Most Critical Requirement of All!

You have all heard disaster stories of computer systems going into production that are over budget, over time, and deliver less than the expected scope. And we have all heard of the new mantra: Business Value/Benefits, Benefits Management, Benefits Realization. This is all good and a step in the right direction to carry us forward from the days of the Iron Triangle of Time, Scope and Cost that some of us may feel is like the fabled albatross hanging round our necks.

BUT - what about new systems, whether those are automated or manual, that when implemented actually damage the business? You can probably think of some and if you do, please comment. This is a situation where something is implemented and everything goes to that hot place in a hand basket, costing sometimes more than the original system cost to repair.

Let's consider the recent implementation of a payroll system in a large organization in a somewhat cold country - the warming of which should not be from the heat generated by systems crashing and burning. The system went in, and it didn't even cover the core functionality of the packaged solution. What was that core functionality? Well, to grossly trivialize it, the system was meant to pay people. What does that mean? In most situations there are categories of people you pay, for example employees (Gross Pay - multiple, sometimes complex deduction = Net Pay) and contractors (Hours claimed X hourly rate from timesheets or invoices = Gross Pay - Deductions = Net Pay). As I said, this is a gross simplification, but I often find this approach serves to raise the real issues to the surface.

What I am really trying to say here is that the technical part of this implementation was, if not a piece of cake, at least very understandable and relatively easy to implement. I mean, really, have we ever paid people before? Have there been payroll and benefits systems flogged by vendors for more than a few weeks? Well, of course! When were computers invented? And before computers, haven't we been paying employees for hundreds of years? This is not rocket science or virgin territory. It takes me back to when managed the implementation of upgrades to the MSA Payroll system at Nova Corporation in Calgary decades ago. I think we can all agree that the technical solution is quite simple.

So what caused all the issues? Aside from the obvious questions we won't get into (but someone should) like "Was there a parallel run?" and "Was there a backout plan in case it didn't work?", one has to delve deeper into the underlying issues.

First of all, how was the contracting managed for this job? Was it competitive such that the job went to the lowest bidder? To that I say "You get what you pay for". Was there an algorithm for selection that put the important things at a higher priority over price, such as "Turn Key solution.", "Includes comprehensive training.", "Guarantees the system will not be implemented until it is proven to work across the organization both technically and organizationally."? These sorts of questions seem to be common sense, yet we all know the rarity of that type of sense, despite its description.

And what type of contract was it? Fixed Price? If so, was everything known at the time of the bid so that vendors can make a reasonable financial proposal? Or did they have to load their proposal down with change order ready assumptions because they didn't know enough to provide a fixed price bid?

Or was the procurement based upon the reputation of the vendor with some sort of executive order to hand them the work based on how they had performed in the past, and based perhaps on possibly unfounded assertions that it had to be done this way to avoid a lengthy procurement cycle in a "burning platform" situation?

And where did responsibility lie for successful implementation?

Now we get to the crux of the matter. IT vendors are usually very good at the technical solutions, but not so good at the human side of things - organization and process, fear of job loss, future expectation for advancement and so on. Often this is shuffled off to the client. Ever hear of the "Train the trainer" solution? You see it in so many proposals, once might say it has become a standard approach.

So far we have talked about the ease of implementing a technical solution and the methods used by large organizations to choose vendors. Now let's talk about the real subject of this article - Organizational Change Management (OCM).

There are many models for change expressed by organizations like ACMP, PMI and Prosci, and from authors like John Kotter and Jeffrey Hiatt. And these are all excellent approaches to OCM, but I have to ask: Are IT companies reading them? Are they putting deliverables and activities into their proposals to account for the steps required to manage change? Or are they weaseling out of it and transferring the responsibility to budget strapped naive clients? And are clients reading these well-founded missives of change management? If so, are they making them an integral part of a bid request? More to the point, are they willing to pay for it?

Change has to come in a package. First we start with the reason for the change strategically. Why are we making the change? What is the change exactly? Who will support the change at various levels (including the top) in the organization? Who be involved in making the change? Who will be impacted by the change? Who will see change on the receiving end? Who will be "right sized" out of a job as a result? Who will be given completely new activities to do in their job and what level of expertise will be required? How will they gain that expertise? How will you know if they have actually gained it? How will the change be woven into the fabric of the organization so that it becomes an integral part of it? How will organization structures be altered as a result of this change? Will there be support for the organizational change? Is a distributed function being centralized? Will there be resistance? How will compliance be achieved? Where will the change be implemented? How will it be implemented? Why? Who? Where? Why? What? How? Kipling and his serving men come to mind.

If you ask questions like these, you will be led down the road of good Organizational Change Management, and you will take into account all of the human factors involved in such a change. Choose the right projects, consider how you will enlighten the organization about what is coming, how you will persuade all levels of the organization to take part, how you will instruct them in the change and confirm that there was a positive effect, how you will weave it into the organization so it becomes an expected part of organizational life. And above all, how you will ensure the benefits you so diligently defined when you started all this have been or will be realized.

So, if you think of your next big contract going a vendor to make a substantial change within your organization, what forces do you have to muster? Organizational support from the top, filtering down through all parts of the organization that are impacted. Clear definition of business benefits. How communication will take place throughout the organization. How quality of the result will be ensured. How the PEOPLE in your organization will want to take part in the change to help you succeed.

Think of your next big change as a package. Strategic planning resulting in the right change being implemented. Selecting vendors who know about the technical machinations required to make your vision a reality, but are also keenly aware of the people side of things and will be there to help you through it if they are not going to do it for you. If your vendor shies away from discussions of communication, awareness, training, checking and operational institutionalization.... run in the opposite direction!

Make sure that the entire picture has been painted before you try to make your vision, your change, a successful reality.

Mike Frenette, PMP, I.S.P., CMC, SMC is a very experienced project manager who likes to post on controversial topics. For his paid job, he teaches Agile and PMP certification courses through his company, CorvoProjectManagement.com. 

 

Posted on: February 08, 2017 10:56 AM | Permalink | Comments (15)

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)

Do you live in a fantasy world?

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. 

Posted on: August 26, 2014 09:20 AM | Permalink | Comments (0)
ADVERTISEMENTS

"In opera, there is always too much singing."

- Claude Debussy

ADVERTISEMENT

Sponsors