Nesma homepage Forums Project control Project Control using QSM SLIM Control

Tagged: , , , ,

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #1974

    We use QSM SLIM Control frequently and we feel that we have more grip on the projects now. However, there are some things we struggle with. QSM SLIM Control is based on the so-called S-curve for product delivery and forecasts are made based on this curve. This means that the tool assumes that after a period of realizing functionality, a period follows in which less functionality (or slocs) is added, and where more test activities and integration takes place. This may be true for waterfall projects and to some extent to some agile projects that are supposed to stop at one time.

    We have a number of contracts where we maintain applications of customers functionally using Agile/Scrum. During these contracts, every sprint functional (and non-functional) back-log items are realized in sprints of 2,3 or 4 weeks. However, there is no specific end date for this. The maintenance can go on for years for all we know.

    Forecasts are therefore not used to estimate the overrun in time or cost/effort, but forecasts are used to estimate how much functionality will be delivered after for instance 12 months. We don’t want to have the S-curve effect happening and we don’t want to forecast overruns. We just want to know how many (COSMIC) function points will be ready on December 31st.

    Does anyone have any idea how to model the tool in order to do so?

    #2582
    Micha Verboeket
    Moderator

    Interesting. That is probably the difficulty of algorithms like this. I’m not sure how much this S-curve does impact projects, but if you for example see the “sprints” as “projects” in SLIM, is it possible to link the projects/sprints together so your 1 year period of interest is an abstracted or aggregated view on the group of projects/sprints?
    I’m not familiar enough yet with the QSM tooling, but i think this problem is inherit to the way these algorithms work, unless the tooling allows to adjust/steer/guide the inner working of it by classifying projects differently (e.g. as agile maintenance). I think this is even bigger problem for DevOps like approaches; new development can also be done in an agile way with different teams for development and for operations and maintenance/3rd level support etc, but with DevOps this cannot be split or estimated separately.

Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.