BradEgeland.com
  • Welcome
  • Blog
  • Expertise
  • Resume
  • Software / Service Reviews
  • Contact
  • Videos
  • Books / White Papers
  • Mentoring Contact Form
  • Awards/Recognition
  • Templates & Downloads
  • Clients
  • Professional Services
  • Past Survey Results

How to Fix Bad Requirements

2/2/2020

0 Comments

 
Picture
Picture
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 our 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 to 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 us 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 a the following four key steps or processes we must go through as a project team when working with our customer in order to get a good handle on real requirements and produce a working end solution for the critical end users…


  • 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 our project customer can supply us in terms of project requirements. We can’t run with these, but cause they likely aren’t going to be complete enough to serve the need of real, complete, detailed requirements. Be 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 our project client – we have to – but it’s not likely that our 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. This usually includes the statement of work, original estimate, assumptions, and planned resources at a minimum.


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 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 then 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 us 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 – thus ensuring better footing as we try to move beyond planning 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 then tracking those requirements through a traceability matrix to ensure they are built in to the design of the solution, then 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.

0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Author:

    Picture

    Brad Egeland


    Named the "#1 Provider of Project Management Content in the World," Brad Egeland has over 25 years of professional IT experience as a developer, manager, project manager, cybersecurity enthusiast, consultant and author.  He has written more than 8,000 expert online articles, eBooks, white papers and video articles for clients worldwide.  If you want Brad to write for your site, contact him. Want your content on this blog and promoted? Contact him. Looking for advice/menoring? Contact him.

    Picture
    Picture
    Picture
    Picture
    Picture
    Picture

    RSS Feed

    Archives

    December 2022
    November 2022
    October 2022
    September 2022
    August 2022
    July 2022
    June 2022
    May 2022
    April 2022
    March 2022
    February 2022
    January 2022
    December 2021
    November 2021
    October 2021
    September 2021
    August 2021
    July 2021
    June 2021
    May 2021
    April 2021
    March 2021
    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    June 2020
    May 2020
    April 2020
    March 2020
    February 2020
    January 2020
    December 2019
    November 2019
    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    December 2016
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011
    October 2011
    September 2011
    August 2011
    July 2011
    June 2011
    May 2011
    March 2011
    January 2011
    December 2010
    November 2010
    October 2010
    September 2010
    August 2010
    June 2010
    May 2010
    April 2010
    March 2010
    November 2009

    RSS Feed

Powered by Create your own unique website with customizable templates.