IFS Scope Tool : Has Anyone Used It In A Real Transformation Programme

Dear Team,

Has anyone worked with IFS Scope Tool, with or without 2c8, to define scope of Project as part of an IFS Cloud upgrade, ERP implementation or business transformation programme?

I’m weighing whether to build it into a programme and want practitioner experience rather than methodology claims. In particular:

1. Scope control: Did it hold scope in/out decisions through delivery, or did it drift into a document nobody updated after design?
2. Traceability: Did scope items actually link through to test scenarios and BoRs, or was that manual reconciliation?
3. Brownfield fit: For existing IFS customers upgrading, was the effort justified, or is it built for greenfield?
4. Ownership: Who maintained it, the partner or the customer’s own team, and what happened after go-live?
5. 2c8: Was it worth the additional license and effort, or did the Scope Tool alone do the job?

If you have used the Scope Tool, would you recommend formally incorporating it into an IFS Cloud programme? Why or why not, and what would you do differently next time?

Even a few practical observations, lessons learned or pitfalls to avoid would be greatly appreciated, whether the experience was positive or not.

Thanks, GK

Direction Is More Important Than Speed

All good questions.  Let me add examples of my experience:

Scope control: I found that the 2A and sometime the 3A documents were very helpful in defining and maintaining the scope.  There were opportunities to enhance the client’s use of IFS applications due to the scope tool’s process diagrams and helped the solution architect, with the input from the application consultants and the client personnel to determine if there were processes in IFS that were not applicable to the client’s operation.    I did not, however, find it so user friendly as to allow the solution architect to simply add processes that were particular to a client’s operations that were not in the original IFS scope tool.

Traceability: I found that most clients had no idea how to develop or even document test scenarios so I feel that the test tracker was a great place to start.  Especially if the solution architect developed and used the end-to-end process flows. I found the scoring and rating portions of the scenarios and the overall test results tedious to maintain.  The same goes with the Books of Rules.  Tedious to maintain.

Brownfield fit:  I haven’t had much opportunity to use the scope tool in upgrades, but where the client is jumping many versions at one, I treat the upgrade as an almost new implementation and use the 2A, 3A, data tracker and test tracker in the same manner.

Ownership: During the map solution phase, the ownership of the scope tool lies with the IFS solution architect and the consultants.  At the presentation of the solution, we transferred ownership to the client however, as they client seldom had access to the scope tool, the IFS solution architect often implemented and republished the changes provided by the client.  As the BoR’s were just MS Word documents, as long as the business flows contained in the document weren’t altered, the documents were maintained by the client.  The data and test trackers were also maintained by the client.

2c8: In all of my IFS implementations during my 25 year+ tenure, I never had the need to alter the 2C5 flows.

Hope this helps!