New WWYD series: Requirements Unpreparedness

08/29/2011

8 Comments

 
Picture
I've been asked by PMI (the Project Management Institute) to create an article for an upcoming series on basically this very concept.  Sort of a "What Would You Do" topic where I discuss an issue I came up against during a project, how I handled it, what the outcome was, and then I call for responses.  The idea is to generate a community discussion so we can all learn from each other's responses on how each of us handled a similar situation or how we might handle it if faced with something similar in the future.

So, I thought this might be a nice ongoing series that I present here as well.  I may or may not present something from my past experience or from a colleagues past experience - it may be real or made up.  And if any of you want a situation or incident discussed on here, just email me and I'll use it for an upcoming topic.

I'm not yet sure how often I'll do these - I'm thinking possible twice per week.  Today's installment is about requirements...a touchy subject for all, I'm sure.

Scenario:  You're starting a project, you have  schedule and price in place and you sit down with the customer and their team to review the detailed requirements that they say they have and that the schedule is built around.  What you find out, though, is that their detailed requirements are really very vague, high-level requirements that will require much more detail and thorough analysis before you have anything useable to build a solution from.

The impact, of course, is that you have the schedule and a price for the project that is based on the fact that you won't have to do this further detailed requirements planning and documentation with the client...they indicated they had detailed requirements as the deal was closed.  But they don't.  What do you do next?  Do you put the project on hold till they have the requirements?  Do you go back to the account manager and have them rework the deal?  Do you create a change order to cover the extra planning time?  Keep in mind - this is the first  PM-customer interaction and starting off with a change order or demand for more money may not sit well with them... it must be handled carefully.

Looking forward to your respones...thanks.

8 Comments
 

The Wonderful World of Scope Creep

10/01/2010

0 Comments

 
In the wonderful world of scope management and scope creep…as a project manager all you have to go on is your organization of the project and your reporting tools. I’ve found that the three best ways to combat scope creep are:

Establishment and signoff (by the customer) of a Scope Statement or Document.

Establishment of a work-in-progress detailed project plan that the customer is reviewing with you on an on-going basis.

Management of the project driven by a detailed project plan and weekly status reviews of the project – that includes the customer – utilizing customized reporting from the detailed project plan.

For #3, my preference is to create custom filters in MS Project and utilize those filters to create 6 customized reports:

Tasks Completed Last Reporting Period
Tasks Started Last Reporting Period
Tasks Planned For Completion This Reporting Period
Tasks Planned To Start This Reporting Period
Tasks Past Due For Completion
Tasks Past Due To Start
Items #1 & 2 cover your areas of Progress on the weekly status report. Items #3 & 4 cover the Planned areas of the status report. And items #5 & 6 cover the Issues area of the status report.

I then include a section in the weekly status report that covers action items, who they are assigned to, and when they are expected to be completed. This area is meant to handle the on-going issues that come up during the project but that don’t really fall under the category of a Task to be included in the project plan.

When your customer needs work that falls outside of the agreed upon scope of the project, then we usually need to turn to two things – a Phased Implementation and/or Change Orders.

Phased Implementations

Many times requirements will either change or become more refined resulting in work that needs to be performed outside the original scope – either timeframe, budget or both. To keep the project on track in terms of implementing necessary functionality within the agreed upon timeframe, one way of keeping the customer happy is with a phased implementation approach.

Usually this will also have budgetary implications as well, since if it is effort beyond the original timeframe then it is likely effort beyond the original budget.

Working with the customer to agree upon implementing ‘x & y’ functionality by June 1st and moving ‘z’ functionality to September 1st is a way of keeping at least most of the project on track while redefining when the full functionality will be ready.
This likely results in one or more change orders, which we’ll address next.

Change Orders

Unless the PM or the PM organization is involved in the sales process (and I think they should be!), then the PM’s first chance to increase cash flow for the organization is to recognize additional customer needs and out of scope items. These are usually handled in the form of change orders. Some customer’s cringe at the mention of change orders and may even have you sign an agreement that there will be no change orders on the project. In those cases you just have to adhere to the original project scope and allow nothing to get in the way. However, when functional requirements are being fully fleshed out and turned into a technical design doc, many IT projects will realize the need for change order work. This can be a need for additional personnel with different skill sets added to the project, more reports, new screens, additional queries built into the software, more integrations than were originally planned…..you get the idea…the list goes on and on. In one case on one of my projects, the customer liked the Business Analyst so much that they wanted him onsite for the entire project rather than just for a couple of weeks at the beginning of each phase of the project. This customer had money and liked the team and wanted to ensure that everything went smoothly. They happily signed on for nearly $100k in change orders over a 3 month period including increased hours and living expenses to accommodate the BA onsite for the duration.

Conclusion

The PM definitely has help from his project team to keep the project on track as originally scoped. The BA and developer(s) will be watching for things that fall outside of the scope during design sessions. However, the PM has overall responsibility to track the scope, identify discrepancies and originate discussions and paperwork that will lead to changes such as a phased implementation and change order work. The earlier this is identified and the quicker it is discussed with the customer, the greater the likelihood of customer satisfaction. Document everything, create detailed change orders and get customer signoffs so that there are no questions at invoicing time.

I originally authored this article for the PM Tips website.  The original post can be viewed here.



Add Comment
 

What the Customer is Trying to Tell You

09/11/2010

1 Comment

 
I’ve discussed the effective listening issue previously. In order to avoid miscommunication, misunderstanding, and heading down the wrong path with something, it is imperative that we listen carefully to our team members and to our customer. We know this…and we all try hard to practice this.

So let’s examine things that our customer says or does and try to figure out what they’re really trying to tell us.

What the Customer Says…

Have you ever been told by your customer that “that’s not what Sales told us”? Or have you been told by your customer that they needed Phase 3 implemented in place of Phase 2 and Phase 2 pushed out to the Phase 3 timeframe? Have they ever said, we’re still gathering our internal requirements from our SMEs and we’ll fine-tune things as we go along?

What They Really Mean…

I have heard each of these things and other similar requests and pieces of information from my customers at one time or another. They are telling you something. Deep down, the customer is telling you indirectly that they’re ill-prepared to start this engagement and therefore risk and issue assessment better be a top priority because you’re going to have a few of them to deal with.

A customer who didn’t iron things out well with Sales isn’t truly ready to start. If possible, you – as the PM – need to step back, have another Sales-to-Professional Services handoff meeting and postpone the start of the project long enough to figure out what you’re walking into.

A customer who hasn’t mapped out their needs, requirements, and business processes well enough for a multi million dollar enterprise-wide implementation to know what phase needs to be implemented when is clearly not fully prepared. Yes, things can change on their end of the business that can switch their priorities around slightly, but for some of these large implementations we’re all dealing with clients who have spent considerable time preparing and acquiring funding. Major changes like switching phases around – which can have major project, budget, and personnel implications – should not be taking place at that late date.

And certainly a customer who is still fine-tuning their requirements while meeting with you to document functional requirements clearly wasn’t ready to get started. Again, this is an example where it is best to halt the project, send the customer back to perform further work on requirements, and then proceed.

Point of View

Now clearly I’m writing this from the Project Manager’s standpoint and what’s best for the delivery team and what’s best for the overall success of the project. I’m not writing this from a customer satisfaction standpoint, or from the standpoint of your organization’s bottom line or the executive management viewpoint. I’m fully aware that most of the time your management is not going to support the notion of pulling the plug on the project to give the customer more time to prepare – especially if that is not a request coming from your customer.

How We Have to Respond…

So, how do we make this work? Well, since we’re all Supermen and Superwomen in Professional Services organizations, we just DO make it work. But seriously, we put our heads down and push forward with the customer to fully define what it is they need. Additional requirements definition, switching phases around, more training, etc. etc. Whatever they need, we try to accommodate.

We still need to pay attention to the timeline and budget and identify where change orders are needed and present those to the customer. But when we’re flexing for the customer, those things that require more time or money are easier to push through with the customer anyway.

I originally authored this article for the PM Tips website - the original post appears here.
1 Comment
 

Dealing with Changing Specifications

09/06/2010

0 Comments

 
I originally authored this for the PM Tips project management website.  The original article is located  here.

I’ve already written a lot about customer indecision, change orders, and the customer’s inability to truly know what it is they want.  And I’m sure I’ll write considerably more on the topic as it is one of the most critical issues we deal with and our ability to manage these situations is often directly tied to customer satisfaction.  It’s our job as project managers to drag that out of them and to anticipate what some of their unstated needs are along the way. 

Even though I’ve shared many of my own thoughts on this topic, I still find that it’s interesting to present other view points and text giving different angles on the same popular topics.  Most of the text from this article comes from the book “Integrated Project Management” by Earl Hall and Juliane Johnson.  This is subsection of their chapter on project change and deals with the how to handle customer indecision and changing requirements.  It’s a little dry, and I think it underestimates the amount of changes that PMs must deal with in the course of an implementation, but fundamentally it’s pretty sound.

Management of Customer Indecisions

A project manager must begin working on a project with the expectation that the customer will request change at least once, perhaps several times, regarding the project outcome(s). The project manager must be prepared for the possibility that a task leader or an external subject matter expert will discover and present a new or better way to perform tasks after the completion of the task list. If the proposed change occurs during the project planning period, it can be accommodated by backing up the planning process and replanning with the change(s) in mind. Before this is done, however, the project manager must create a new, revised specification statement and clear it with the customer, appropriate subject matter experts, and key team members. The project must always be working toward one clear goal, and all prior specifications must be destroyed.

Change requests that arise during the project's planning process are not hard to deal with if they are few and infrequent. Changes do interrupt the planning process and cost time and money, but aside from that and the frustrations the team experiences, they can be handled effectively. When a customer is uncertain about exactly what he or she wants and frequently changes his or her mind this must be dealt with as a special case.

Customers often want a project to begin before they have decided on a precise outcome. They may not expect to be able to precisely define what they want for some time. However, integrated project management (IPM) is based on the premise that a precise outcome statement—specification—must be decided upon before planning can begin. Both experience and logic support this proposition. Nevertheless, when thinking is at the scope level, it is often reasonable for the customer to be uncertain of the precise outcomes. Can an integrated project be started under these conditions? The answer is yes. A preliminary specification can be created. A project manager begins the project by leading the creation of this specification.

As the project manager helps migrate the project from scope to specification, he or she aims for a precise specification that will capture the current best estimates of what the outcome should be. This specification will be used in the initial planning and execution of the project. At the same time, the project manager puts in place a project specification change procedure to deal efficiently with the outcome changes the customer may desire later on.

Experience has proven that this approach is more efficient than simply starting in a general direction, then adjusting, redirecting, and reorganizing as an outcome concept emerges. It must be understood that in IPM, replanning will be a major event and will not take place piecemeal. It will not occur often during the life of the project. Small and frequent modifications of the specification must be prevented because such practices kill projects.

The rationale for insisting on the creation of a specification before starting project planning derives from the processes that must take place when the change in a project is executed. Before a project can be changed, there must be something to change. The effort to get the customer to agree on what the "current" best estimate of what the outcome should be is defined within the statement of work. Sometimes, customers do not decide on exactly what they want until they see what is involved in providing them with what they think they want. Sometimes, the general dimensions of an outcome are identified, but the exact characteristics of the outcome must wait on "research in progress." The customer and the project manager agree that a precise outcome definition within the general framework of the expected outcome will enable the project manager to begin the project planning. It also will provide for the startup of project execution. The initial plan is expected to be relevant when the revised outcome statement is decided upon.

Creation of the initial project plan gives the project team something useful to do now, and it creates a good plan for the team to examine and change when a specification revision is presented. This fits in with the fundamental process of project change. When a change is proposed, the original project plan—the Gantt chart andthe resource table—is the necessary reference for the considerations of what can be done and what this will cost.

Add Comment