Hello! This is Aidan Duffy from iloveoracle.com
In this blog post I want to discuss the Requirements Phase, one of the 6 Key Skills of a Functional Consultant, in particular creating the MoSCoW List.
Functional Quadrant – How to use your existing skills to break into Functional Consulting, and develop the full functional skillset from there.
Link to Functional Quadrant Post
Requirements Workflow – Diagram showing the requirements workflow; these are the areas you need to concentrate on.
Link to Requirements Workflow Post
Key Work Products – Requirements
- RD.005 – System Context Diagram
- RD.045 – MoSCoW List
- RD.011 – Future Process Model
- RA.023 – Use Case Model
- RA.024 – Use Case Specification
- MC.010 – Business Data Structures
So the MoSCoW List has four major steps. Firstly, you would have a MoSCoW workshop. At the very beginning you would have a workshop really to explain to the client the approach with MoSCoW prioritization for requirements, explain to them how it works. You would have a workshop to explain that first of all. And that would probably be led by the project management actually with you in support and often the rest of the project team might joining in that meeting as well, so it would be like a big session being led by them.
And then you list all the requirements, people who are kind of shouting out from the audience, I wanted to do this. You’d write the thing down and then you would have a big prioritization meeting. On a project team with the client, you might have an internal first-go at the prioritization and then you go to the client with an initial version which is a good way of doing it.
Link to RD.045 MoSCoW List Work Product
The ones that I’ve illustrated here are the requirements which would have been captured at the statement of work stage. The statement of work is one of the early stages in the project which the functional consultant is really involved in, but as we have said this is a document that’s really managed by the project manager because it’s such a key indicator of scope and it’s really an excellent control document.
So these are really high-level requirements, so it’s to reconfigure Oracle order to cash with the functional currency of the new Greek drachma; reconfigure purchase to pay and record to report; also HR activities; banking activities and payroll activities. We also have the stakeholder, so the order to cash manager; the P2P manager; CFO, which is the Chief Financial Officer.
One further comment I have at this point is, this is a living document. We update this document as we go through the phases of the project so we obviously know who the stakeholders are for order to cash.
As to how the objectives or the requirements will be met, that’ll only become apparent as we go into design phase. Some of the other requirements would be to mitigate the risks of the Greek exit, so this is something that’s put into the statement of work. But at that point and even at our phase right now, it’s not easy to see exactly how that’s going to happen but they are recorded anyway.
Uses Business Terminology
Another key point is, as you can see, it’s all in business language. It has nothing to do with functionality or Oracle. It’s like to allow trading in the new currency, to understand our exposure in euro versus the new drachma. So that’s kind one of the key requirements that the CEO would have and there is also one, which the CFO came up with during the statement of work which was to maybe have some real-time currency exposure reporting.
You can see in the Priority column that we’ve got the priority, which stands for Must have, Should have, Could have, and Won’t have. And the first eight or nine are Must Have because this is what we need to do to be able to survive in Greece. And then this real-time currency exposure reporting is a Could Have.
So basically we kind of prioritize the requirements using this document. And that happens really early in the process, at the statement of work stage, and the stakeholders are reminded of the priority of various requirements that they have.
This is our business process that we’re using the details, business requirement to illustrate in our documents. The source for these requirements is our GL and MoSCoW meeting. The first two requirements are a priority that is noted as Must Have; the first one is we need to be able to synchronize the general ledger currency exchange rates with the AmeriTel treasury website and we need to be able to revalue the General Ledger balances.
The owner is the GL controllership team. The complexity is average because we are fairly sure that we can do this using standard Oracle functionality. The risk or impact is low. And we’ve also assigned a use case ID.
The second requirement then is the ability to revalue GL foreign exchange balances according to the new exchange rates. The third one is the ability to report on currency exchange rates. And the last one is a requirement that was brought up during the GL and MoSCoW meeting, what was set as Won’t Have.
So due to the time constraints and the rush to get our new solution set up, we record the fact that the business requested an automated interface of currency exchange rates from the treasury’s website and during the same meeting we decided that this version of the solution won’t have that requirement.
Using MoSCoW to Generate Future Project Work
As we said before, the MoSCoW list is the living document throughout the project and is repeatedly updated and refreshed. It’s a good idea as a functional consultant to keep your eye on the MoSCoW document because you’ve got the prioritization of must have, should have, could have, wont’ have. A lot of the should have, could haves become future requirements. So if you can look at what’s coming up as future requirements with your client, you know where they’re going to be spending money on the project next and then you can tell your conversations on the project, when you’ve got yourselves into the areas, where the future requirements are going to coming up.
Key Questions on MoSCoW List:
1. Define COTS – Custom Off-The-Shelf.
Custom Off-The-Shelf, COTS is an acronym that Oracle have developed. It just means a package, purchasing a package. So when they say COTS, it means you are implementing a package as opposed to writing pieces of software from scratch.
2. Can the COTS (Custom Off-The-Shelf) MoSCoW list become agile down the line of implementation?
Yes, it can actually and sometimes with an agile implementation as well. And as opposed to being a requirements-driven solution, you do a solution-driven project rather like the new Oracle Cloud functionality, it’s not really a requirements-driven implementation, it’s solution-driven. The requirement is Oracle Financials Cloud.
There’s no other requirement. It’s like buying a Microsoft product. When you go into the shop for a Microsoft product, you don’t show up with your long spreadsheet with a 150 different requirements of I want to be able to use this particular font and drag-and-drop and have crazy formulas, your requirement is to buy Microsoft Excel. That’s the way Oracle is going.
So to a certain extent the MoSCoW list can turn into a bit of a sprint list, a hit list for agile methodologies.
3. If we record requirements as could have or won’t have, is this not like changing the goalposts? And would it have any impact on the work that was carried so far?
No, in fact it wouldn’t. Because what you do is during the initial release of the scope of what you’re building, you’d only actually work on the must haves and should haves, the could haves. Well, won’t haves are never going to be done. But the could haves are put down to the bottom of the list, and it would often be agreed that they won’t be actually implemented in the current iteration or release of the project that you’re doing.
But why it’s interesting to note those things actually is because they’ve been identified as requirements and as the more higher priority requirements are been implemented and moved in transition into production, some of lower priority requirements may well be picked up and carried forward in new project put in place to implement those things.
So it’s good idea to keep an eye on the RD.045, the MoSCoW list to see what’s coming in the work stack for our client.
- Prepare workshop
- Formulate top-level requirements, consisting of an Actor-Goal List and a list of Supplemental Requirements
- Convene workshop
- Categorize each top-level requirement.
Create Prioritized Requirements List which contains the high-level requirements (Actor-Goal List and List of Non-Functional Requirements), divided into the four categories (Must Have, Should Have, Could Have and Won’t Have)
Requirements Phase – MoSCoW List Work Product Page
Ask Questions in the comments below
Review questions and add general consulting comments on our http://iloveoracle.com/oracle-functional-consultant-community/
Please download the presentation deck and wmv here:
Download Deck Link
Download Presentation WMV Link