ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Displaying items by tag: project requirements
Project Management Blog

392Click Here to Listen to the Interview: http://bit.ly/2s3LsEJ
Read More: http://bit.ly/PMPodcast392

My goal of having these show notes on the website is to give a quick and concise introduction of the podcast topic and to tell you what you can expect to learn from it. Sometimes I am right on point and sometimes I’m a little more vague.

And tomorrow, when you are back at the office working on your project requirements your goal will be to correctly and succinctly describe the requirements for that project your company is going to launch. The big difference here is that your descriptions have to be 100% on point. You cannot afford to be vague, because requirements that can be misinterpreted is a sure-fire way to doom your project. So what can you do to improve your requirements?

The problem of poorly written, ambiguous, and inconsistent requirements is something that Jordan Kyriakidis (https://www.linkedin.com/in/jordankyriakidis/) has thought about a lot. And his answer to this problem is not only a list of “21 Top Tips for Writing an Exceptionally Clear Requirements Document” (https://qracorp.com/write-clear-requirements-document/) but also to use computing power. Yes, there is actually a software that will scan your requirements document and tell you what's wrong with it.

But we’re not going to talk about the software much, because that would be pretty boring here on an audio podcast. Instead, Jordan and I look at the root causes of poorly written requirements and then we introduce you to the most important 6 out his 21 tips. In that way you can start using your brain power to write better requirements

Published in Blogs
Tuesday, 02 December 2014 19:43

When to Implement a Requirements Freeze

There are different opinions about when to implement a requirements freeze. When considering a freeze, it is important to keep the following facts in mind.

You Cannot Freeze Business Change

Business is always changing, and the project solutions that are built must reflect these changes. However, you can still freeze change requests. Freezing change requests is simply a technique to bring closure to the project. Remember that when you build a solution for your client, the project only represents the initial steps in the product lifecycle. Once the system goes into production, there may be follow-up phases to the project, or the solution will go into a support and enhance stage. This stage could easily end up representing ninety percent, or more, of the entire solution lifecycle. The enhancement process is the way that the application is changed over the long-term. So, do not seek to freeze business change overall, only to freeze changes that would extend the life of the initial project. If changes are needed after the project freeze is implemented, they go on the backlog to be addressed later as enhancements.

All that being said, you do not want to deliver a solution that does not meet the business needs. That would not make sense either. If you implement a requirements freeze, you must also have a process in place for getting around the freeze. What you are really doing is gaining agreement with the client sponsor to raise the threshold for scope change management. During the freeze, for instance, it may be that all change requests need to be approved by the sponsor personally. If the sponsor understands the benefit of the change request, as well as the cost and impact to the project, he may still approve the request if it is important enough. However, even important changes may not get approved during the freeze. What may happen instead is that the change will be prioritized high as part of an enhancement request after the solution goes live.

Fixing Errors is not Affected by the Requirements Freeze

You may wonder whether system testing is the right time to implement a freeze. Remember that the freeze is on business requirements changes. Of course, if you find problems or errors in the system test, they need to be corrected. System testing is a time when you do stress testing, usability testing, documentation testing, performance testing, etc. As an example, during requirements testing you may find that you misinterpreted a requirement, which will require a change. This is not a change to the requirements, but the correcting of an interpretation error. This may be allowed. During stress testing, you may find that your hardware is not powerful enough to take the load. This may require changes to the system configuration, or a change in how the transactions are processed. Again, this may be required under the freeze.

However, hopefully your client is not adding new business requirements during system testing. When you get to system testing, in many cases you have to retest when changes are introduced. For instance, if a change request is allowed during system testing, you must make the change, unit test it, run integration tests, and potentially rerun all the system tests. This is very disruptive, and if possible these changes should wait until the enhancement process after implementation. In fact, at this point in the project, you may even defer some errors that were uncovered during testing if they do not have a major impact to the value of the solution.

Summary

If you consider implementing a requirements freeze, it shows that you have recognized that continued change requests will jeopardize your ability to deliver within your budget and deadline. You can then come to an agreement with your sponsor to allow the team to focus on a fairly stable system for completion of the testing and implementation process. Critical change requests are still allowed, while less critical changes are deferred until after implementation, during the enhancement process.

At TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. .
Published in Blogs

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 353 guests and no members online

Got something to say?