Post a comment or question you would like me to respond to. It can either be a question or dilemma that are a facing from a project (please no identifiable company or product names) or a topic that you would like covered.
Post a comment or question you would like me to respond to. It can either be a question or dilemma that are a facing from a project (please no identifiable company or product names) or a topic that you would like covered.
August 24, 2008 at 10:23 pm |
Hi Jessica!
I’m not going to comment anything. But, I have questions that need your help to aswer or explain it. According to PMBOK, we need to manage the project scope stated for the project. In any projects such as software project, we also need to manage the software project requirements. My question are:
1. What are the relationships and differences between scope and requirement for software projects?
2. Is requirement a subcomponent in scope management? Are we controlling the requirements based on the scope stated earlier?
Thank you.
Shikin.
August 25, 2008 at 12:21 pm |
Hi Shikin,
Thanks for your question. I will preface my answer by saying that my response will be what I do in practice and may not map to a PMBOK answer on a test but is definitely true to the principles of PMBOK.
Yes, we need to manage to project scope. Depending on the organization you are working in, this will mean a varying amount of stakeholder buy-in, documentation and sign-off. For this answer, I will go through a fairly textbook example of how I would get through the requirements phase of a software development project.
First, with the stakeholders I would write a scope statement. The scope statement would include not only a statement of project scope, but also define stakeholders (project decision makers), customers (recipients of the end product) and potentially some budgetary and timeline requirements.
The scope statement for a software project with be a high-level (and this is the key) of what is being delivered. For your software project it will be a paragraph or two at most stating what is being requested. For example, it could be as high-level as “Deliver a set of enhancements to the existing Employee Database and GUI to add additional career information, job categories and resume data. Reports will be added to be run on demand to query this information.”
Ok – so that’s very high-level and somewhat shorter than what I would put in a scope statement – but give you an idea. But it does define the basic parameters of what you are agreeing to. At this point I would get sign-off from stakeholders that we agree that we are working only on the Employee Database and only in the area of new career information.
At this point, I would work with my team and we would only offer a very high level effort or timeline estimate – not a commitment but an estimate. As you know, estimates at this stage have a variance of +/- 100%. But I should be able to give a good estimate f how long requirements will take – which will be the next checkpoint for the stakeholders.
Next, I would move into the requirements. So yes, in my opinion, in software requirements are a subcomponent of the Scope. And yes, you should use your signed-off scope statement as a way to stay in the boundaries of what you should be writing requirements on. Any requests outside the scope should put on a separate request list and not included. The requirements phase is where you will define every detail, following SMART requirements to define exactly what you will deliver.
Once you believe you have identified complete requirements you would again get sign-off from customers and stakeholders. With the requirements in hand, you work with your team to better refine your effort estimate (non accurate +/- 75%). Based on your estimate, your stakeholders may want to adjust the scope. (i.e. if the schedule proposed is too long, they may narrow the scope or vice versa.)
Any time a customer or stakeholder requests requirements that are outside your scope statement – this is considered scope creep as they are potentially increasing the amount of work your team needs to complete to accomplish the goals. The benefit of getting a formal sign-off on your documents is that you can refer back to these to keep everyone on track.
In the event that the stakeholders or customers want to increase the requirements scope then you would re-open the scope statement, revise it and get sign-off again. This may seem like a tedious process but it helps everyone understand the impacts they are having on the project and opens the discussion for why you may need to change the proposed schedule.
If you don’t manage these events carefully customers don’t recognize that what they are asking for are scope creep and then they perceive the increase in the time estimate as the project team’s inability to plan a project. A miscommunication that is so prevalent on projects. Project Management is all about communication.
I hope this answers your question. If not, I hope to hear back from you and we can continue this discussion