• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Agile Coach - What to put on Schedule?

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Agile Coach - What to put on Schedule?

    I'm currently appealing a blanket SDS determination.

    There's some talk of me being rehired as an Agile Coach. There's no D&C or MOO. How could I word the schedule to make it as IR35-friendly as possible? I'd be working across multiple projects etc.

    Any suggestions gratefully received.
    ...my quagmire of greed....my cesspit of laziness and unfairness....all I am doing is sticking two fingers up at nurses, doctors and other hard working employed professionals...

    #2
    Should be pretty easy. It's all about specific deliverables and targets you will achieve in the timescales of the contract.

    You obviously know the role but I found this article.

    What is an agile coach? A valuable role for organizational change | CIO

    You could quite easily take a whole host of deliverables straight out of that and list them. Obviously tailor them to what you know about the role but that article gives more than enough goals to be achieved to make up a good statement of work IMO.

    I'd use three columns. First with a high level statement of aim, second with some bullets detailing how or what you will deliver and the last one empty. You'll fill the last one in with results that the client will sign to agree deliverables have been met.

    Just scanning that article one example could be..

    Knowledge and tools

    Analyse as is knowledge and tools
    Create knowledge plan to achieve agreed outcomes
    Implement knowledge within agreed timescales
    Source and deliver tools to achieve agreed outcomes
    Provide consultancy to ensure tools knowledge continue to meet client requirements

    In the last box you will detail the training and tools delivered and to who at the end of the period and the client will sign agreeing you met the agreed deliverables.

    That make sense?

    I don't know what agile coaching but I'd say 5 or 6 high level entries with associated bullets would do.
    Last edited by northernladuk; 26 February 2020, 10:32.
    'CUK forum personality of 2011 - Winner - Yes really!!!!

    Comment


      #3
      No-one else need reply to this thread. That's a nailed-on answer. I really appreciate it.
      ...my quagmire of greed....my cesspit of laziness and unfairness....all I am doing is sticking two fingers up at nurses, doctors and other hard working employed professionals...

      Comment


        #4
        As a fellow agile coach, I'll add a little more specificity in the type of things I intend to be including in the deliverables section of SOW's I work under going forwards;

        - Completion of an Agile maturity assessment
        - Delivery of an agile maturity roadmap
        - Delivery of X number of agile training workshops as per agreed schedule
        - Consultancy / delivery of of X role (E.g. Scrum Master) as per agreed schedule

        I'd be looking to include payment milestones upon completion of the first few deliverables in particular as these will be documents. Milestones linked to completion of X number of training sessions

        I'd also be looking for relief events to be included for the scenarios wherein I'm unable to complete a deliverable due to omission or inaction on behalf of the client. E.g delivery of X number of training sessions is dependent on client ensuring staff attend these sessions.

        I'd price this up based on an assessment of requirements following consultation with the client and have %'s of the total price based on payment milestones.

        Just my thoughts..

        Comment


          #5
          Originally posted by LordAsriel View Post
          As a fellow agile coach, I'll add a little more specificity in the type of things I intend to be including in the deliverables section of SOW's I work under going forwards;

          - Completion of an Agile maturity assessment
          - Delivery of an agile maturity roadmap
          - Delivery of X number of agile training workshops as per agreed schedule
          - Consultancy / delivery of of X role (E.g. Scrum Master) as per agreed schedule

          I'd be looking to include payment milestones upon completion of the first few deliverables in particular as these will be documents. Milestones linked to completion of X number of training sessions

          I'd also be looking for relief events to be included for the scenarios wherein I'm unable to complete a deliverable due to omission or inaction on behalf of the client. E.g delivery of X number of training sessions is dependent on client ensuring staff attend these sessions.

          I'd price this up based on an assessment of requirements following consultation with the client and have %'s of the total price based on payment milestones.

          Just my thoughts..
          I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

          Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).

          Comment


            #6
            Originally posted by DigitalUser View Post
            I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

            Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).
            Valid point. It may be that you do a level of 'Discovery' up front, with this SOW engagement completing upon completion of investigations around the as-is and production of a maturity assessment / roadmap for further maturity.

            With this knowledge, you may then be able to enter a delivery focused phase under a new SOW with concrete deliverables around what you've discovered within the initial phase.

            Comment


              #7
              Originally posted by DigitalUser View Post
              I'd put some concrete outcomes in place as well - the deliverables are merely outputs, in itself they don't do anything to benefit the client.

              Flexible Contracts might be of use in this instance. I'd also break the engagement to do some initial work to establish what's needed (otherwise you're rocking up on site without knowing what the 'right' deliverables are).
              I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

              It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

              Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.
              'CUK forum personality of 2011 - Winner - Yes really!!!!

              Comment


                #8
                Originally posted by northernladuk View Post
                I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

                It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

                Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.
                Bang on... Outcomes are out of the control of those who actually deliver.
                Always get paid based on delivery, or T&M. Never on something so vague as an outcome (unless you're the boss who decides what the outcome was).
                See You Next Tuesday

                Comment


                  #9
                  Originally posted by northernladuk View Post
                  I wouldn't. Concrete outcomes usually are dependent on a lot of things you have no control over. Once you start putting those in you have to work on contingencies if you can't deliver. Technically if you are paid upon delivery of that outcome and it doesn't happen you don't get paid. I do think that's probably one step too far for contractors to swallow. I'd stick to agreed deliverables. Clear enough for direction but woolly enough to be flexible if it goes wrong.

                  It's going wrong on mine already only three weeks in and we can't meet the main one due in two months. If that had been concrete then the whole relationship could go south for no reason. Instead we'll just to business with an eye on the deliverables as guidance. We will then re-align the deliverables for the next piece of three month work.

                  Establishing what is needed is absolutely key in a schedule. It's impossible to write a decent roadmap without some fact finding. I'd be seriously worried if I was given a difficult schedule with no chance to investigate what we have before piling in and changing it. It's also a very nice consulting term so defining an As-Is view always looks good as well as being essential. It's 101 stuff when you are going in delivering change.
                  It's a fair point - what I would say is that the guiding principle here is that the risk is shared with the client. If the client doesn't play ball (and this is evidenced along the way) then you still get paid. I'd also break down the SoW into smaller work packages which roll up to the overall deliverables + outcomes. YMMV with all of this type of work, of course.

                  Comment

                  Working...
                  X