In this second part of a six part series on issue management, we’ll examine the process of identifying the customer’s business processes and how issues and changes will be managed against those identified processes. 

Identifying business processes

The key to a rock-solid project and a usable end solution delivered to the customer is a detailed understanding – and, yes, mapping – of the customer organization’s business processes.  You can know the requirements, you can know the stakeholders, you can connect with the ultimate end users, but unless you understand the customer’s business processes then you still may not deliver a usable end solution.  Furthermore, you can’t always assume that the customer understands their own business processes.  Indeed, mapping those out is going to be similar to the grueling task of extracting the detailed project requirements from your customer.  They know some of what they need to know, but the rest is something you’re going to have to help extract and document.  Otherwise, the requirements you start to build a solution against may not completely align with the customer’s business processes and goals.  It’s a process – and it’s one you must plan for in your project planning and schedule.

Once you and your customer fully understand the business processes and have documented detailed project requirements that do, indeed, align well with those business processes, then you’re ready to move forward with the project.  At this point, you’re managing two things – the design and development of the solution AND the issues and changes that will undoubtedly arise through better understanding of the requirements and how they correlate to the needs of the customer and their business processes.

Managing the issues and changes

Managing project issues on any project is an ongoing endeavor.  No project makes it’s full run without some critical issues arising that need tracked, managed, and dealt with.  The same goes for change requests.  It’s a rare case when a project completes with out at least one or two sizeable change requests that needed to be initiated, tracked, and implemented in order to keep the final solution in line with the business processes and requirements for the project. 

Those issues and changes can be managed using a spreadsheet or as part of the weekly project status report.  However, the use of a web-based automated tool is likely going to be your best bet in order to provide the project manager, project team, project customer, and all stakeholders with meaningful reporting and insight into the nature and status of all issues and change requests.  The key to accurate management and resolution of issues and changes is the capture and reporting of critical and detailed information about each issue and change.  Those responsible for the main tasks of resolve the issues and implementing the changes will perform better in those roles if they know exactly what needs to be done and what the expectations are that they are performing against.  The online issue and change management tool will perform these tasks better than any spreadsheet or table the project manager can create.

This issue management discussion is part of an ongoing six part series.  In part 3 will look at the detailed part of issue management and change management in terms of what data needs to be captured and managed.

If you’re looking for a solid enterprise issue management tool, check out Gemini.  Gemini gives maximum flexibility with minimal effort to manage real world problems efficiently and quickly.

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.