Skip to main content

Tag: Requirements

5 Things to Know Before You Start the Project

Written by Brad Egeland on . Posted in Articles. 6 Comments on 5 Things to Know Before You Start the Project

Eager project managers – and new project managers – may like to jump in head first into a new project and show enthusiasm to prove to their senior management that they are go-getters. That’s nice, but it may also be stupid. These overly eager PMs may be sending the wrong message to their leadership, who are really looking to see if they show any knowledge at all about how they should go cautiously into the night on a project… not jump in with pistols blazing.

The best way to start the project properly is to go into the engagement knowing a few things first. Make sure both feet are firmly planted on the ground, and you are ready to serve the customer appropriately.

This all comes to mind mainly because – amazingly – I was handed a project where nothing was known. Seriously… nothing. We had a developer working on the project already. He was doing some preliminary work on an interface for the project working with a customer-side project manager. Other than the generic interface we were tasked to do, we knew nothing about the project. Nothing. And I was about to jump on a call with the sponsor on the customer side. I had nothing to go on – no documents, no status reports (everything had been verbal sprint meetings to this point), and no statement of work (SOW). Nothing. Ummm…ok. Actually really it was not ok.

So, here’s my list of a 5 key things I like to know going into a project:

What exactly is expected of the PM and team? It is imperative that the project manager knows what the team should be delivering. Without proper documentation such as a statement of work, previous notes, or status reports, a project manager is blind heading into any discussion they are having with the project sponsor and customer team. It’s a no win situation – no ability to plan, no ability to ask or answer questions intelligently. Before starting a project or taking over a project, even before engaging the client, the project manager needs an idea at least of what the project involves.

Is funding in place? Is there money for this effort? This tells you how serious the project customer is. Are they looking for free advice or are they really planning to engage your services? I had a potential consulting client who I suspected was just looking for me to propose something so he could refine his idea for a project. He basically wanted a free strategy proposal. I created a proposal – a good one and it was detailed – but I also required that it be a paid deliverable. He was surprised, but he paid for it. I knew it was the only money I was going to get from him because he was just fishing and I couldn’t afford to give my time away for free.

Does a legacy system exist? Are we building something new or is there a legacy system in place that currently does this work? Knowing this can help project managers figure out a few things like what not to do, or possibly give some added insight into current business processes. This knowledge may make the project more affordable for the client by being able to propose an add-on to the existing functionality to cover the needed feature rather than completely rebuild the system. There are always options – PMs just need the full picture in order to propose those options.

What data integrations will be necessary? If you are still working through the financials and pricing for the project, then whether or not loading legacy data into the system and how this data will be integrated are two critical pieces of information. It may seem trivial, but data can be very complex. Loading old data may mean data needs to be cleansed – basically cleaned up and reformatted to fit into a new solution. And as far as integrating it into a new solution – tying it into the data fields and getting the new functionality to talk to the existing data the way it needs to can be very difficult. This is key information that is needed for requirements definition and pricing.

What is the timeframe for the project? Finally, when is this project needed? You may start out putting together a plan based on what you have been given to and are about to propose a 14-month timeline to the project sponsor. It would be very helpful to know from the project sponsor that they MUST have the solution within 6 months. Knowing the timeline before you put the effort into the schedule allows you to either plan to meet that incredibly tight timeframe or plan a phased implementation. You will need to begin planning negotiation points on why your approach will work for them.

Summary

Heading into the unknown is tough. Project managers can waste a lot of time and look like fools in the process if they try to plan for and prepare a project engagement that they know little about. The key is to get as much information as possible up front. Knowing the right information is critical to planning properly, making good estimating and team building preparations, high-level requirements definition, and knowing how to prepare for and execute any project kickoff activities. Going into a project engagement or any discussion with the potential project sponsor completely blind is dangerous and can lead to a project not getting off on the right foot.

What’s your take on this? When have you had to take on a project with nothing to go on? What did you do? If you were a consultant, did you skip that project? Did you dig further? Did you head into meetings with no clue hoping to gather some helpful information? What other key info – especially on tech projects – other than what I’ve listed above, do you usually need to know before getting started or even meeting with the client?

Don’t forget to leave your comments below.

A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Written by Elizabeth Larson on . Posted in Articles. 9 Comments on A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are–discussed, dissected, and the subject of many blogs. Aren’t they “old school” and not needed in today’s Agile world?

They are still needed and are, in our opinion, among the most useful tools/techniques practitioners have in their business analysis toolkit. Without going into the historyi, use case models, both the diagram and the narrative text, provide a structured way to think about our work, work that we’ve always had to do in software development, but which has been simplified with use case models.

Although project managers who are not business analysis practitioners do not need to create use cases, they should know what use cases are, be familiar with key terms, and understand why they are important to getting the requirements right.

This series of articles will focus on these key points.

Why use cases?

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding a project’s scope and the use case narrative is invaluable for getting the detail needed to build the product or service. And although used primarily in software development, use cases are also useful when creating processes and developing equipment. They work wherever there is an interaction between people and what those people need to do.

Terms, terms, and more terms

A rose by another name, as we know, would probably smell the same, and use cases if called something else would serve the same purpose. Use cases are so named because they describe how people want to use their software or equipment.

However, it does sound a bit technical. It sounds like the kind of technique that a project manager could easily leave in the hands of more technical resources and forget about. And that would be too bad, because use cases help projects in many ways, as we’ll describe below.

Years ago Elizabeth gave a presentation on use cases. She remembers saying that despite how useful they were, if it had been up to her, she would have called them something else, something less technical and more accessible to business stakeholders. She remembers one upset participant who said that it was a good thing no one listened to her! That’s probably true, but it still seems to us that use case terms are a bit arcane for most PMs and business stakeholders. So here are the key terms explained:

Let’s begin with a working definition of what a use case is. We like to think of it as the conversation back and forth between actors and a system. Which is all well and good if we know what actors are and what the system is. Let us explain.

  • The system contains all the work we want to do on the project. We like to use the microwave as an example. As a microwave user when I heat up leftovers, for example, I am outside or external to what the microwave does, so I am not part of the systemii. I am an actor who interacts with the microwave system, telling it what I want done and getting heated leftovers as a result. Which brings us to actors.
  • Actors are always outside the system and always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.

Let’s practice on a couple of examples. If actors are always external to the system and always interact directly with the system, in the following two examples, am I an actor?

  1. Example 1. The system in this first example is an automated banking deposit application. I walk by a bank lobby on my way to work. One day I decide to take a cheque to deposit it in the bank. I stand in line with the deposit, and finally when it’s my turn I hand it to a teller who enters the transaction into the automated deposit system. Am I an actor?iii
  2. Example 2. The next time I have a cheque to deposit I don’t want to stand in line, or even go to an ATM to deposit the cheque. Instead I scan the check using my bank’s app on my smart phone. Am I an actor?

Why PMs Should Care About Use Case Diagrams

Below is an example of a use case diagram. We will explain all the pieces in our next article.

Larson May27Figure 1 – Use Case Example

Use case diagrams are one of the several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram has some key benefits:

  1. It’s an easy way to engage business stakeholders. If we explain use cases using business terms, they can visualize what their system will include, helping get a big picture of the scope.
  2. Because it’s a useful visual, our stakeholders are more inclined to be specific about their desired featured and functionality,
  3. Use cases are almost universally appreciated by the development team, so that there is less time spent translating the business requirements into technical specifications.
  4. Use cases become test cases with acceptance criteria. Whether the team prefers the “Given-When-Then format or the components of a use case, as odd as it sounds, the result is the same.

Stay tuned for future articles on use cases. We will show examples of use case diagrams, explain how to build them, describe why we should create use case narratives, and yes, we’ll explain how use cases provide the same information as the Given—When–Then format.

Don’t forget to leave your comments below.

References

i Elizabeth saw an Ivar Jacobson presentation on use cases about 10 years ago. Jacobson, of course, is one of the ‘three amigos” (with Grady Booch and James Rumbaugh) who founded Rational Software and the Unified Modeling Language. “I had been working with use case models for several years at the time of his presentation. If I remember right, one of the things I learned was that the idea for use cases was rattling around Jacobson’s mind since his work at Ericsson, many decades before this presentation.”
ii Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It is cleaner and simpler to think of ourselves as an actor interacting with the microwave system.
iii Be careful. We need to define what the system is. In the first example we said it was an automated banking deposit application. In this example I do not interact directly with the system as we’ve defined it, so I am not an actor. The teller, however, is an actor because they do. In the second example we have not defined the boundaries of the system so we do not know who the actors are. It is quite possible that a user scanning a check for deposit is an actor since they are interacting directly with a system. It is also possible that the system is the back end and the user does not interact directly with the system. These examples show the importance of defining the system in order to understand our scope.

About the Authors:

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored three books: The Practitioner’s Guide to Requirements Management, CBAP Certification Study Guide, and The Influencing Formula. She has also co-authored chapters published in four separate books.

Elizabeth was a lead author on the PMBOK® Guide – Fourth and Fifth Editions, PMI’s Business Analysis for Practitioners – A Practice Guide, and the BABOK® Guide 2.0, as well as an expert reviewer on BABBOK® Guide 3.0.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored three books, The Influencing Formula, CBAP Certification Study Guide, and Practitioners’ Guide to Requirements Management.

5 Lessons from Working with Agile and Waterfall Teams

Written by Angela Wick on . Posted in Articles. 4 Comments on 5 Lessons from Working with Agile and Waterfall Teams

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?

Here is what I’ve learned about Agile and Waterfall approaches:

1. We need more collaboration in EVERY project.

What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?

Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!

Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.

What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.

Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.

Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.

2. Agile projects have BA tasks.

“Agile” roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.

Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.

In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.

3. Techniques don’t change.

Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.

Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM  User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.

We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.

4. Stop Polarizing Agile and Waterfall

Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.

Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:

  • Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
  • Bringing flexibility and fluidity back into the world of software development
  • Creating an efficient and effective process that would bring meaning and purpose into every task

Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.

I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.

5. Don’t freak out your stakeholders.

So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.

It is important to help all stakeholders understand the agile mindset, but we don’t need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?

It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.

It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.

So, now that I’ve had my say, do you agree? 

Don’t forget to leave your comments below.

A PM’s Guide to Requirements Modeling Part 2: Concurrent Requirements Modeling

Written by Elizabeth Larson on . Posted in Articles. 3 Comments on A PM’s Guide to Requirements Modeling Part 2: Concurrent Requirements Modeling

This article is the second in a series on requirements modeling with the emphasis on why PMs should care about modeling requirements. Last month we spoke generally about models, the benefits of modeling requirements, and introduced the relationship between the iterative nature of eliciting requirements and modeling them. This article discusses the concept of concurrent requirements modeling, a structure that helps us elicit the detail needed for a complete set of requirements.

Quick Review

What is a model and why should we care? A model is a representation of reality, like a model car, airplane prototype, or graphical design (e.g., a CAD drawing) of a house. As they relate to requirements, models usually consist of text, graphical representations, or both. To get good requirements, we need to ask the right questions. We need to go beyond the “who, what when, where, and why” questions and get to the detail we need. Models help us do just that.

Concurrent Requirements Modeling

OK, so models help us ask the right questions. But which models should we use? Is one model better than the others? Sources such as the BABOK® Guide and PMI’s Business Analysis Practice Guide offer dozens of potential models. We certainly don’t have time to use all of them. Of course there is no one answer to the question of which model is best, but we can explore which models are best suited to our projects. When we are involved with improving processes, and there are a myriad of reasons for doing so, one or several process models work well. When we are building business intelligence applications for doing information analytics, or simply developing quick reports, data models are helpful. When we developing applications and need to describe the interaction between people and the software, use cases are appropriate. And prototypes are helpful to a variety of different types of projects. For software applications, all four are important, and when we elicit and model requirements using the appropriate models pretty much at the same time, we can get to detailed requirements more quickly than if we use just one ore even two model types.

We call this approach “concurrent requirements modeling,” which is different from concurrent component engineering, or concurrency, commonly used in developing objects and e-solutions. Concurrent requirements modeling focuses on obtaining business requirements, not on building software. It suggests that by modeling business data, business processes, interactions of users and systems through use cases, and prototyping, hidden requirements will surface more quickly than if we tried to think of questions without modeling or if we tried to build the product and elicited needs in an ad hoc way. In addition, each type of modeling effort supports and enhances the other modeling efforts and encourages analysts to ask their customers the kinds of pertinent questions that drive out hidden requirements.

Figure 1 below describes the interrelationships among the different types of functional requirements. The models are particularly useful for software requirements, but can also be useful for many aspects of business analysis. The models and their interrelationships are shown below.

larson April1Figure 1: Concurrent Requirements Modeling

A brief taste of the four model types

Data models. Once thought to be solely the domain of the very technical developers and database administrators, data models help us understand our stakeholders’ information needs, including many of the all-important business rules. Business rules provide consistency by identifying how companies want to operate their business, and supporting these business decisions across projects. Business rules include such things as policies, calculations, sequence of events, limits, and business decisions. We’ll talk more about the business rules related to data in our next article.

Process models. Our projects result in changed processes. Sometimes it’s a big change and sometimes a small one, but every project changes how people do their jobs. In order for us to understand what particular changes mean to our stakeholders, we need to know what they are doing today and how that will be different when our project is completed. Process models help us with this understanding.

Use case models. So much has been written about use cases. Discussions about their usefulness keep surfacing on LinkedIn groups, a few people saying that they are not useful, particularly on Agile projects, while others with equal passion building a solid case for why they have always been useful and still are. The authors side with the latter. Use cases help us answer very important questions about the interaction with software or pieces of equipment, and provide the structure needed to ask the right questions relating to that interaction.

User Interface models provide prototypes. They might be done using sophisticated software or the proverbial back of a napkin or something in-between. The point is that these prototypes help stakeholders see a picture of the end product, enabling them to provide feedback and suggest changes long before it’s developed.

Working together. When building software, data models answer the questions what data do our stakeholders need to input and when they do, what information is displayed on the user interface (screen). Process models give us the screen navigation. The touch point between the data and process is where there is interaction between the end user and the software. Use case models provide us with what we need to know about this interaction. User interface models graphically depict use cases. More about that in a future article.

What does this mean for project managers? As PMs we might not do the work ourselves, but we need to ensure that work is done. So it’s important for us to be able to have enough of an understanding of these models to ask the right project questions of the resources who will be doing the elicitation and modeling. We also think it is important to understand the value of each model type and why using multiple models will yield better project outcomes. Last, we can be far more helpful in discussions about elicitation activities, tasks, estimates, risks, etc. when we have an understanding about the subject at hand.

In the next article we will examine the benefits of data modeling and what data questions surface when we model our information requirements.

Don’t forget to leave your comments below.

About the Authors:

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored three books: The Practitioner’s Guide to Requirements Management, CBAP Certification Study Guide, and The Influencing Formula. She has also co-authored chapters published in four separate books.

Elizabeth was a lead author on the PMBOK® Guide – Fourth and Fifth Editions, PMI’s Business Analysis for Practitioners – A Practice Guide, and the BABOK® Guide 2.0, as well as an expert reviewer on BABBOK® Guide 3.0.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored three books, The Influencing Formula, CBAP Certification Study Guide, and Practitioners’ Guide to Requirements Management.

Turning Bad Requirements into Good Requirements

Written by Brad Egeland on . Posted in Articles. 4 Comments on Turning Bad Requirements into Good Requirements

Bad requirements or no requirements are definitely not the best way to start any technical project. But most project managers will tell you that you aren’t likely to get your best requirements from your project customer – no matter how certain they may be that they have thoroughly documented everything for you. The problem is, some project customers aren’t even certain they know the right problem or need that the project is going to be addressing for them. In those cases – and that’s often from my experiences – there is no way a project client could have good, detailed requirements waiting for you. They don’t even know the real problem yet…they’ve likely only documented a symptom.

The bottom line is this – customers are not often known for providing good requirements for the solutions they are seeking from the project teams. Ideally, customers would have met internally with their end users and subject matter experts (SMEs) to determine exactly what the problem is, what the real project is, and at least what the high-level requirements are that need to be met by the project team as they develop and implement the solution. In reality, those end users are all too often overlooked leaving us to roll out a solution to them that may or may not help them to do their jobs better. And if it doesn’t solve the need – no matter how we point our fingers, it is we who have failed the project customer, not the other way around.

In order to get to the point where the project team knows what needs to be done and exactly what is expected of them, a few steps must happen. From my experiences, I’ve narrowed it down to the following four key steps or processes we must go through as a project team. In order to get a good handle on real requirements and produce a working end solution for the critical end users, the project team must…

  • Get initial requirements from the customer at project initiation
  • Kick the project off formally and set expectations
  • Define detailed requirements with the customer
  • Track requirements with a traceability matrix

Let’s look at each of these in more detail.

Get initial requirements from the customer at project initiation

Like it or not, our starting point needs to be whatever the project customer can supply in terms of project requirements. We can’t run with these because they likely aren’t going to be complete enough to serve the need of real, complete, detailed requirements. By definition, in order to be a good requirement, it must be unitary (define one thing), complete, consistent, non-conjugated, traceable, current, unambiguous, specify importance, and be verifiable. We may get there with the help of the project client – we have to – but it’s not likely that the client will get there on their own.

There’s no way the project manager can know how ready the customer is with their true project request until he sees what preparation they’ve already put into the engagement. Plus, knowledge of the customer’s preparation status is absolutely necessary to adequately map out a project schedule and how much time the planning phase is going to require – something that is a critical input into the project kickoff session.

Kick the project off formally and set expectations

With all customer pre-project preparation information in hand, the project manager is now ready to put together a draft project schedule based on this information and any information obtained at the handoff from sales to project management. At a minimum this should include the statement of work, original estimate, assumptions, and planned resources.

Once the project manager has the draft project schedule ready, a kickoff agenda in place, and a formal presentation prepared, the kickoff meeting needs to be held with the customer and the customer project team. This is the meeting where expectations are set, the schedule is reviewed and agreed upon, deliverables and milestones are finalized, and the final project planning gets set in motion.

Define detailed requirements with the customer

Following the project kickoff meeting, the project team will work with the customer on further project planning activities. The key activity is the detailed definition of the project requirements including asking the right questions of the customer, customer team, and customer SMEs and end users to truly identify what the real needs of the project are. That’s the only way that the project team can effectively identify the detailed requirements for the customer and the only way they can confidently embark on developing a project solution that they know will meet the customer’s end user needs once the solution is deployed at the end of the engagement.

Track requirements with a traceability matrix

As I’ve stated, documenting accurate, detailed requirements is important, but that’s not the end of the requirements work. The best way to both document requirements and to know that those requirements have been built in to the final solution is to create a requirements traceability matrix. This becomes a living, breathing matrix for the rest of the engagement. It will be created in design, updated in development to show where each requirement is built in to the solution, checked in testing and user acceptance testing to be sure all functionality works, and then signed off by the customer as part of system acceptance at deployment.

Summary

Requirements are the lifeblood of the project. Bad requirements = a bad project that usually involves much rework, a blown budget and timeline, and usually ends with a dissatisfied customer and a frustrated end user base. That’s bad…obviously. These four steps or actions are not going to guarantee success or that you even have great requirements to work from. Projects fail, requirements change without realizing it, and customer systems are often complex – meaning it’s not easy to capture good requirements every time. It’s our responsibility as project managers to build adequate time into the project timeline and budget for planning and defining project requirements. This ensures better footing as we try to move beyond planning and into the real work of designing and building out the customer solution. Plus, good and detailed requirements makes user acceptance testing easier (and better) which also serves to ensure those end users are getting what they need in the long run.

By understanding the real issue or issues, documenting detailed requirements, and tracking those requirements through a traceability matrix to ensure they are built in to the design of the solution, the project team can be confident that the customer’s end users will receive a solution that they can productively use. The end result will be a successful implementation and a satisfied project customer.

Don’t forget to leave your comments below.