Ask an Expert

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.

Advertisements

Like this:

LikeLoading...

7 Responses to Ask an Expert

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?

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

Yes, I personally think that Project Charter and Project Scope documents are 2 of the most important documents that help get everyone focused on what needs to be done. I think a great place to start can be to use a version of the PMBOK (Project Management Book of Knowledge). I think it is a good reference book and offers good high-level ideas of what topics should be covered by document type. In general though, this is what I try to answer with these two documents:

Project Charter – purpose is to get formal approval to begin the project. In some environments this may not be necessary, but in many there is a difference in the hand-wavy “Sure we should do this” and the actuality of getting support to execute the project. This document is often very short 2-3 pages and I try to answer the following questions. Many of them seem “duh” but that is the point – if we don’t get everyone on the same page, each person may be making a different set of assumptions of outcome and that is surely to lead to project difficulty and/or failure.

Project Purpose – 2-3 sentences on what the project outcomes are expected to beProject Objectives – 3-5 specific bullets of the objectives that are going to be achievedProject Justification – What is the business reason why this project is being taken on. This confirms that there is justification and not just someone’s whim project.Project Dates – what are the requested start and finish dates (note requested – we aren’t confirming anything here – but it can become revealing if scoping reveals that the target dates can’t be met)Summary Milestones – high-level 3-5 key milestones w/ projected datesSummary Budget – some basic estimate of total cost to complete (high-level SWAG)High Level Risks – are there known risks at the get-go that should be shared – no more than 2-3Project Stakeholders – **key area** who is participating in this project (check PMBOK for definition of a stakeholder)Project Sponsor – **key area** perhaps the most important item – who is sponsoring or funding this in the org. Who has the authority to say go/stop/provide budget.

Very similar for the Scope Statement (only done after the Charter is approved). The project sponsor signing off on the project is the go-ahead to start a project – don’t start before if you want to minimize execution risk.

Scope statement is also short 2-4 pages and should describe the high-level boundaries of what is being accomplished. This document is critical to get initial agreement to what is being done and for the purpose of managing scope-creep. If you don’t write down and ratify an initial scope statement it is nearly impossible to have a leg to stand on when it comes to saying “But that wasn’t in your original request”.

Scope Statement:Problem Statement – a brief statement 1-2 paragraphs of what the problem is that you are trying to address with the projectProject Goals – what are the 3-4 goals of the project. These are key to define customer satisfaction of what is trying to be achieved. These in part define the success criteria of the projectIn-scope – list the key 4-6, perhaps a few more items that describes the items to be completed. Helps focus the audience on the goals of the workOut-of-scope – one of the most important items. Take some time to think of key items 2-4 that are out of scope – things that are not going to be included. This really helps get everyone on the same page in terms of what is trying to be achieved, and what might not be possible within budget/time/skill set, etc.Project Constraints – list any known constraints that you are up against that may affect the project. Perhaps it is a date that can’t be moved (i.e. preparing for a National Convention – a constraint will be that the convention date is set and all work needs to be completed prior)Project Assumptions – list a few items that you are assuming to be true to be able to execute on the project – perhaps it is availability of particular resources, whether it be people, hardware, etc. Perhaps it is assuming that you can hire the appropriate team in time,etc. This is important b/c if the assumptions don’t hold to be true – it impacts your project.Key Deliverables – this may be the same (or fine-tuned from the Project Charter)Key Milestones – this may be adopted from the Project Charter as well – and should indicate estimated dates.

I hope this helps you get started. Sorry for the delay in the response, I knew I needed to find some time to write a complete reply. Best Wishes – Jessica

I am getting mixed up by trying to answer a simple question on the phases and sub phases of SDLC. I have the phases listed INITIATE, PLAN, IMPLEMENT, CLOSE and sub phases Reqs/Analysis, System Analysis, System Design, Build, Test, Deploy. Am I on the right track? Relatively new to this, would appreciate insight. Cheers!

Yes, you are absolutely on the right track. You have 4 of the 5 process groups that PMI uses to organize projects. The last one is “Monitor and Control” which is overarching across the entire program. For additional guidance, you might choose to use a PMBOK guide as a framework for mapping your individual steps. I’m not advocating that PMP is the only way to manage a project – but the book provides a good framework and reference for these types of questions. There is a chart in one of the early chapters – that lays out exactly what you are saying – overarching phases paired with key activities for each phase. The layout is field agnostic but it is logical enough to map to any SW/HW process. Hope this helps.