Requirements

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

About this Blog

RSS

Recent Posts

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!

How do you run your virtual meetings?

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 (14)

Rethink Requirements: The Natural Language Processing Approach

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!

Posted on: January 24, 2017 08:00 PM | Permalink | Comments (1)

Quality - Consider it in all Knowledge Areas!

Categories: Quality

When you think of quality as a PM, does your mind race to the quality management plan section of your project management plan? If so, do you think you normally cover all aspects related to the other nine knowledge areas? If not, it may be time!  

Quality is somewhat ephemeral, isn't it? It's like asking, "How long is a piece of string?"  We have to get much more succinct than that when we are dealing with quality on projects.  Consider using a Deliverable Expectation Document, where you go over a deliverable with a client, and define the level of quality needed, to which requirements it relates, and who will review and sign off the final deliverable. Maybe this is the Definition of Done and/or the Acceptance criteria in an Agile project.

So, how does quality relate to the other knowledge areas? What should you consider when composing your Quality Management Plan? Or conversely, what should you consider about quality in each of the other plans? Here is my take on it: 

  1. Scope - Of course, scope is where we start with quality. What is in scope, what is not in scope. Once we understand scope, we can start asking questions about the level of quality required. For example, if the scope of the project is to create a manual set of processes to help in the selection of products for monthly sales in a do it yourself store, what does quality look like? Do you know? Of course you don’t! You will need to discuss with your sponsor and stakeholders to figure that out. Maybe part of the process needs to take into account several factors, such as what is overstocked, what is being phased out, or what will draw customers to buy other related items that are not on sale. Or maybe it is about rotating from department to department to make sure everything in the store is covered over a period of time so that all types of customers are drawn to the store. So what does quality mean in this example? Probably that each of these situations are taken into consideration in the processes so that all the needs are met.
  2. Time - Quality processes take time, and time is money. So we must always pay attention to the cost of quality. It is fairly obvious that you can’t introduce so many quality-related processes that we spend 90% of our time in the project performing then. On the other hand, if we don’t have sufficient effective quality control processes, we may spend a lot of time in quality assurance finding issues that shouldn’t really be there, and sending work back to be redone. And as we all know, rework costs time …. and money!
  3. Cost - We’ve already established that any process will cost time, and so it will also cost money. We’ve also established that rework, caused by ineffective quality control processes, costs time, and so it, too, costs money. What is the cost of the quality processes you will have to implement? What is the cost of not implementing them? Rework: time and money!
  4. Risk - What are the risks associated with quality? They are always present. There is the risk of not being sufficiently detailed in finding out what we are supposed to be building and to what level of quality. We try to mitigate this with DEDs/Def of done/Acceptance Criteria, and so on. There is that risk of rework. There is the risk that the product as produced will not be accepted. There is even the risk that we may try as best we can to get the definition of quality down accurately through discussions, models, documents and definitions, but that we end up getting it wrong anyway! So, taking quality into account during risk planning, identification, quantitative analysis, qualitative analysis and response planning is critical.
  5. Communication -  Communication deliverables need quality definition like any other. And, of course, communicating what needs to be produced, who will define it, who will approve it is just as important. So, quality comes into play when producing communication deliverables, and is also used as the main tool in defining the required levels of quality for each of the project deliverables.
  6. Human Resources - Quality is, of course, something that each member of the project team must own. They should be asking very detailed questions about what it is they are supposed to be producing, to what level of quality, and asking questions about how to ensure they are producing the right thing the first time, that which is expected by the client (QA). They should also be asking about the processes for ensuring they have produced the right thing (QC). If they don’t feel they have the skills to meet the expected level of quality, they should speak up, ask for training or mentoring, and even to be replaced if the timing for it would be poor, so they can work on a project where their stronger skills can best be utilized. Your team members should be asking questions like, “Where’s the DED or Definition of Done?”, "what are the quality assurance processes?”, “What are the Quality Control processes”? "Who will be accepting the product I am producing?”, “Who are the relevant stakeholders?”, and so on. Your team produces the deliverables that must meet the defined levels of quality and acceptance criteria. They must perform any necessary rework to get their deliverables into the required state. They are key. They control and assure quality.
  7. Stakeholders - Of course, your project’s stakeholders are key to defining required levels of quality by being instrumental in development of DEDs, DoDs, and detailed definition of what the deliverables should look like, who should be involved in the requirements definition and who will review and accept the final deliverable. They help define your work. They sign off on your work. They can send work back for rework. Could they be any more important? Your client and sponsor are in this group, and so are all the others who can impact your project’s quality expectations. Who could be more important? If you have the best team on the planet, producing exactly the wrong things to the highest levels of quality as defined by the wrong stakeholders, you have nothing. So, find out from your sponsor who to involve, then involve them!
  8. Procurement - Quality is just as important when it comes to procurement. You need to translate your stakeholders’ quality requirements for your vendors and then you need to be sure your vendors are producing the right stuff. You may also want to get into the internal processes of your vendor’s deliverable production and overall project management so you can be sure they are running a quality operation. If not, you may find that the deliverables sent to you by the vendor are not what you, or more importantly, your stakeholders, expect. And as we all know, the buck stops with you, the project manager. You are responsible for quality on the project, and that includes everything delivered by a vendor. So in your planning, what processes will you have in place to ensure quality work from the vendor?
  9. Integration - So, we have seen that quality permeates ALL of the nine other knowledge areas, and must be dealt with in all process groups. Integration is the realm of the PM and by its very name insinuates interplay among them all. As we have seen, quality is no exception. In fact, it is probably the rule. So build it into your projects. And remember - you can't test quality

How do you plan for, assure and control quality on your projects?

Posted on: November 08, 2016 03:01 PM | Permalink | Comments (3)

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

Ever been on a project where your client has already chosen a package solution?  How many times has it been based on a solid set of business requirements, complete with all those great models you can read about in PMI’s Business Analysis for Practitioners: A Practice Guide?  

In my experience, and I won’t mention any names or locations to protect the innocent and avoid shining a light on the guilty, business requirements for packages can be very sketchy, often based on a document listing many unsorted and uncategorized sentences meant to represent requirements.  In the worst cases business requirements can even be overlooked entirely.  

Why do you suppose people feel that because it is a package, it will have all the necessary functionality for a business, and that if it does not, the business can adapt?  Or that the package can be modified to meet requirements at little cost?  

Familiar with the famous term “fit gap”?  This is where requirements, however they are documented, are compared to package functionality, and the package with the highest score wins. Sadly, such analysis is often performed at far too high a level.  And worse still, the number of requirements that cannot be met are often presented as the inverse of “percent fit”.  

Sadly, the cost of changing a packaged solution to meet the 10% of requirements it doesn’t meet can often be greater than the cost of developing something to meet all requirements from scratch.  Or, the 10% some other package didn’t meet could possibly be met at a much lower cost, or even eliminated altogether if they were a low priority.

It’s a bit of a conundrum, isn’t it?  Do you spend time and money defining your business requirements in advance of making a build or buy decision when you know quite well that you are going buy a package regardless of what requirements are discovered? Are you just going through the motions? Or maybe you think your organization can adapt to the business model upon which a package was built, thinking that the package represents best practices in the associated business.

I believe no matter the route you are choosing, eliciting business requirements from the beginning and defining and managing the detailed requirements will bode well for any organization so that they can measure the success of whatever decision they make to achieve their business goals. After all, if you don’t ask the questions, you will never know the answers!

What has been your experience with the installation of packages that have been installed to satisfy specific needs? What about ERPs? Have your clients/users been satisfied with the result? Were requirements sufficiently defined prior to package purchase and installation so that a baseline comparison could even be done?

 

Posted on: July 07, 2016 03:00 PM | Permalink | Comments (1)

How do you run your virtual meetings?

Meetings, bloody meetings! We all remember the video John Cleese created many years back (well, some of us do, anyway), and the recent video "“Conference Call in Real Life” that is great for some big yuks. But how do you run effective virtual meetings?  

I felt prompted to write this article when I saw the many comments after a colleague posted a link to the “Conference Call in Real Life”. I thought this demonstrated that there may be a need to provide a few guidelines on how to conduct virtual meetings effectively.  Professional behavior in virtual (and, of course, in-person) meetings is the key to success.

Collecting requirements virtually is becoming more and more common as organizations try to keep costs low.  So it is more important than ever to use virtual meeting tools effectively. But it isn't all about tools.  As is so often the case, it is more about the people who use the tools.  After all, a wise man once said that a fool with a tool is still a fool.  

So, let’s get on with it, shall we?

Tips for Meeting Chairs

So, you need to have a virtual meeting.  Well, guess what?  Just a like an in-person meeting, you need an agenda.  Send it out ahead of time and ask that people prepare. Be clear about the meeting purpose and objectives. If it is a recurring meeting, allow people to make agenda suggestions in advance in case there are burning issues they feel need addressing that you didn’t think or know to include. 

When you communicate the agenda, lay out the ground rules for the upcoming meeting.  You can probably derive some ground rules from the following tips designed to help you engineer a successful meeting:

  • Tell attendees you’ll be sticking to the agenda and that “other business” can be addressed at the end of the meeting if there is time, otherwise the item needs to be added ahead of time to a future meeting.
  • Everyone is expected to “arrive” on time. In the meeting announcement, include immediate methods for testing the desktop sharing/presentation software that will be used so technical glitches can be identified and solved in advance.
  • Provide a phone number for road warriors or those who will not be connected. Ideally, though, everyone will join via computer so they can see shared screens.
  • Display action items on a shared screen. If they are not accurate, attendees are expected to speak up.
  • Input is expected, but one person will not be allowed to “hog” the floor.
  • For small meetings, ask people to locate to a quiet area and keep their mics on so everyone can hear what is going on. If someone is interrupted, stop the meeting until they are free again, just like in an in-person meeting when the board room door opens and someone interrupts.
  • Insist that attendees use headsets with microphones. Those built into computers are not good enough – they will make you sound like a robot, or like you are in a cave, extraneous noises will be picked up and echoes may result. 
  • Use a solid internet connection. If your wireless connection is flaky, use a wired connection. 
  • If material is being presented for review during the meeting, ask that it be sent around in plenty of time before the meeting so it can be reviewed, especially if feedback is being sought.
  • Create a collaboration site for storing meeting minutes, or if it is a project meeting use the project repository. I use SharePoint for this.
  • If a formal presentation is to be delivered, ask everyone to go on mute until it is time to ask questions or make comments. This is not a time to multi-task, though. It is only to make sure the speaker can be heard.
  • Record presentations and post them to the collaboration site. Make sure you let everyone know it is being recorded, and remember to click the record button before introduction of the speaker.
  • Start the meeting five-ten minutes early to ensure there are no technical glitches.
  • Check meeting tracking beforehand so you will know who to expect.
  • Send a communication five minutes in advance to all invitees to announce that the meeting will begin in five minutes.
  • Don’t start the meeting until everyone is there, or you have allowed sufficient time for laggards (I use five minutes as a guideline). Assess whether to cancel the meeting if key people are absent or not enough people show up.
  • Let people know how to use the chat window, and whether you will accept private chats.  If questions and comments may be typed in their entirety in the chat window for addressing at the end of the meeting, say so.  This is an effective way in very large meetings to handle Q&A without interruption while allowing attendees to ask questions or make comments while content is fresh in their minds.
  • Consider the use of cameras. They are not usually necessary for meetings where everyone knows one another.  But if there are new people, and they are comfortable with it, you can use cameras for a round-table introduction.  If they are not comfortable with it, consider using still pictures.

As mentioned above, you need to share decisions made and action items to which attendees commit during the meeting with the group. I find most virtual whiteboard tools are cumbersome, so I usually share a document using a word processor like Word or Google Docs. 

If you are an ambidextrous cranial sort who can take notes while thinking, chairing and talking, you can do this yourself.  Otherwise, ask a colleague in advance to take on that responsibility. But watch what is being typed, because it has to be accurate and reflective of what everyone agreed. 

Make note only of important items and action items that have been agreed, including who is responsible and when the item is due.  You can send these notes to meeting participants directly after the meeting.  No more creating minutes after the fact and having people disagree with what was written since they will already have seen what was recorded during the meeting.

Highly visible decision logs and active action item lists on your collaboration site are priceless.

Noise can render a virtual meeting ineffective.  Be sure extraneous noise is addressed politely and firmly. If you have to, force mute.  Occasionally, people are interrupted and don’t control the situation well, talking with the intruder and failing to go on mute. You can mute them and decide to continue the meeting or not.  You may need to use alternate means like their cell phone to communicate with them so they know they have committed a virtual meeting sin. This is the same as if someone gets up from an in-person meeting and leaves the room.  Should you continue the meeting?  Your call… maybe ask the person or the attendees as appropriate.

Having trouble getting some people to contribute? Try doing a round table about a specific issue, suggesting that each person talk for no more than a minute or two and that if they have nothing to say, just “pass”.  Some people are too shy to interject, but are happy if they have time to think about what they want say and know they will receive the “talking stick” eventually.  Start with someone you know won’t mind talking to give the more introverted a chance to collect their thoughts.

Tips for meeting participants:

  • Review all materials sent in advance of the meeting and make notes so you will cover the points you feel are important.
  • Behave as if you were in an in-person meeting. Avoid distractions.    Respond.  Participate.
  • If you have something to say, and you can’t get a word in, use the meeting chat function as instructed by the chairperson or use the “raise hand” function if there is one and the chairperson has said it is in play. 
  • Don’t hog the floor. If the chairperson indicates you are taking too much time, respect the interjection and allow others to speak. Be concise, brief, to the point.
  • Don’t make noise. Be aware of where your microphone is in relation to your mouth.  Heavy breathing is never appreciated.  If you hear it and it is not you, and the chairperson is not reacting, politely, perhaps with a little humour, announce that it appears someone is chewing on their microphone, or an obscene caller seems to have joined the call.
  • Be humorous. It’s alright to have fun at virtual meetings, as long as meeting objectives are met and time is not wasted. This doesn’t mean you should tell jokes.
  • Don’t interrupt speakers. It is up to the chairperson to manage people who are speaking too long. If you feel the meeting is not being managed well, consider private messaging the chairperson.
  • If you see anything inaccurate being shown in the shared action list, speak up, particularly if it is your action.
  • Be respectful. Take notes. Ask questions. Make comments. In a few words – be fully engaged, be present.

There is a certain degree of flexibility with virtual meetings that can save time and money, and you can take advantage of easy to use features (like record and share screen) that are sometimes more difficult to do in an in-person meeting. 

Virtual meetings don’t need to be like the Virtual Meeting in Real Life video, as humorous as it is since it is so very close to the reality of those in first-time virtual meetings. Let common sense, respect and preparedness rule the meeting, and success will be yours – and your team’s. 

 

Posted on: May 02, 2016 09:56 AM | Permalink | Comments (9)
ADVERTISEMENTS

"Do not worry about your difficulties in Mathematics. I can assure you mine are still greater."

- Albert Einstein

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events