Loading ...
Sorry, an error occurred while loading the content.

Re: Project Capitalization

Expand Messages
  • pborsella
    ... necessary ... Alicia...the first thing we had to do is agree that we needed to record our time purely for accounting purposes. This is an important and
    Message 1 of 5 , Jan 31, 2006
    • 0 Attachment
      --- In scrumdevelopment@yahoogroups.com, "aliciayanik0724"
      <aliciayanik0724@y...> wrote:
      >
      > I'm sure this has been asked and answered before, but a quick search
      > didn't turn up enough information for me. I'm looking to understand
      > how other organizations, while using Scrum, gather the data
      necessary
      > to capitalize projects (and pass an audit).
      >

      Alicia...the first thing we had to do is agree that we needed to
      record our time purely for accounting purposes. This is an important
      and sensitive matter, because we don't want time tracking to be used
      as an indication of productivity. Next, we worked with our Finance
      department to understand which activities qualify for capital and
      which do not. So, for example, "development" would be a capital
      activity, but "project management" might not qualify.

      What does "project management" have to do with Scrum? This is the
      Finance category that we used to account for the daily Scrum. 15
      minutes a day x the number of folks on the team x multiple capital
      projects adds up! This amount of time needs to be recorded so Finance
      knows how much gets capped and how much doesn't. Remember, "project
      management" is an example of a non-capital activity...your Finance
      dept. may have others.

      So where do you record this? We don't want to interfere with the
      logging of "what's left" burndown maintenance, so we keep the Finance
      time separate from the burndown. This of course meant that we needed
      a time-tracking tool. Once you know which activities don't qualify,
      you can then ensure that the time spent on those activities get
      recorded and submitted to Finance.

      I'm trying to explain in a few paragraphs what took many hours to
      devise. You'll need to spend some time evaluating the best way to do
      what you're asking without violating Scrum principles.

      I hope this helps some...Pete
    • mpkirby@frontiernet.net
      ... Are you referring to the financial requirements to determine whether development expense is considered an R&D line-item, or a SAG line-item? (where R&D
      Message 2 of 5 , Feb 1, 2006
      • 0 Attachment
        On 1 Feb 2006 at 7:19, pborsella wrote:

        > --- In scrumdevelopment@yahoogroups.com, "aliciayanik0724"
        > <aliciayanik0724@y...> wrote:
        > >
        > > I'm sure this has been asked and answered before, but a quick search
        > > didn't turn up enough information for me. I'm looking to understand
        > > how other organizations, while using Scrum, gather the data
        > necessary
        > > to capitalize projects (and pass an audit).

        Are you referring to the financial requirements to determine whether development expense is
        considered an R&D line-item, or a SAG line-item? (where R&D items can be capitalized up
        until product launch, and SAG items must be expensed.)

        As I understand the rule, if you are developing a new product, or a major upgrade that
        customers must pay for, it is considered R&D. Maintenance releases, or feature releases
        that are covered under existing service contracts are considered SAG.

        At least that was how it was explained to me.

        What we do is allocate a budget of "stories" to each of the product programs. THe stories
        are prioritized into a single backlog, but we are mindful of the budgets. So the "continuing
        engineering" budget for a past program (That might coutn against SAG) may only be 1000
        story hours. But the new product might be 1500. So during the upcoming release (which
        might have different end dates), we make sure to prioritize 1000 story hours worth of stories,
        but no more for the older product.

        We track against stories as well, but by and large don't close the financial reporting loop.
        Aparently the "budget spent" is more important then the "how it's actually spent", but they
        tend to be reasonably close.

        The obvious "scrum" flaw in this approach is that it's possible to deliver a low proiority feature
        for a product above a high priority feature for another product whose budget is exhausted. I
        think the real answer is to tie the budgetting to tracking, and prioritize between programs, but
        that's very difficult to do in the large corporate environment.

        Mike

        ---
        mpkirby@...
      • Sherri Dotson
        Peter, This is great information and it will be great to exchange dialogue on your experiences again. : ). We must talk soon. Sherri Dotson ...
        Message 3 of 5 , Feb 3, 2006
        • 0 Attachment
          Peter,
          This is great information and it will be great to
          exchange dialogue on your experiences again. : ).

          We must talk soon.
          Sherri Dotson

          --- pborsella <pborsella@...> wrote:

          > --- In scrumdevelopment@yahoogroups.com,
          > "aliciayanik0724"
          > <aliciayanik0724@y...> wrote:
          > >
          > > I'm sure this has been asked and answered before,
          > but a quick search
          > > didn't turn up enough information for me. I'm
          > looking to understand
          > > how other organizations, while using Scrum, gather
          > the data
          > necessary
          > > to capitalize projects (and pass an audit).
          > >
          >
          > Alicia...the first thing we had to do is agree that
          > we needed to
          > record our time purely for accounting purposes.
          > This is an important
          > and sensitive matter, because we don't want time
          > tracking to be used
          > as an indication of productivity. Next, we worked
          > with our Finance
          > department to understand which activities qualify
          > for capital and
          > which do not. So, for example, "development" would
          > be a capital
          > activity, but "project management" might not
          > qualify.
          >
          > What does "project management" have to do with
          > Scrum? This is the
          > Finance category that we used to account for the
          > daily Scrum. 15
          > minutes a day x the number of folks on the team x
          > multiple capital
          > projects adds up! This amount of time needs to be
          > recorded so Finance
          > knows how much gets capped and how much doesn't.
          > Remember, "project
          > management" is an example of a non-capital
          > activity...your Finance
          > dept. may have others.
          >
          > So where do you record this? We don't want to
          > interfere with the
          > logging of "what's left" burndown maintenance, so we
          > keep the Finance
          > time separate from the burndown. This of course
          > meant that we needed
          > a time-tracking tool. Once you know which
          > activities don't qualify,
          > you can then ensure that the time spent on those
          > activities get
          > recorded and submitted to Finance.
          >
          > I'm trying to explain in a few paragraphs what took
          > many hours to
          > devise. You'll need to spend some time evaluating
          > the best way to do
          > what you're asking without violating Scrum
          > principles.
          >
          > I hope this helps some...Pete
          >
          >
          >
          >


          __________________________________________________
          Do You Yahoo!?
          Tired of spam? Yahoo! Mail has the best spam protection around
          http://mail.yahoo.com
        • Dymond, Robin
          Peter, Sherri I think the thing that what is missing for capitalization of a project from this approach is Value. The focus of this tracking effort is on
          Message 4 of 5 , Mar 2, 2006
          • 0 Attachment
            Message

            Peter, Sherri

            I think the thing that what is missing for capitalization of a project from this approach is Value. The focus of this tracking effort is on expense, but we don't develop features and stories to spend money. If a project is funded, it should have a business case, and a model that outlines how revenue and profits will be generated, or in the case of regulatory, costs (fines, litigation, etc.). Models you can use are well understood by accountants, they include Net Present Value (NPV), Internal Rate of Return (IRR), Return on Investment (ROI), etc. The valuations of the project determine the capital required.

            A traditional project approach is that after the budget is allocated, the project, its expenses, drivers, and team become completely disassociated from the Value - everything becomes a cost, and treated equivalently. This is a problem, because it removes the primary motivation for doing the project(s) from the view of the team, middle management, supporting services, etc.

            An Agile project should include transparency from the business case to the product backlog and the features that are to be developed. In this way the team knows the Value of the work they are doing in every iteration. This also motivates the team and product owner to find ways to get the first release into production early so the features can begin generating Value for the business. For example, if four planned releases of features account for 60%, 25%, 10%, and 5% of the business value, then this should be reflected in the accounting. The team should then ask: is it possible to release features that deliver 30% of the business value into production at an earlier time?

            Whether you capitalize Scrum (or PM)  as overhead or R&D is debatable, I would argue that you can't have R&D without PM functions, and if that person is 100% dedicated to development projects, then they are in the Capitalization/R&D bucket.

            The main thing we now need to do is get away from the cost based mantra of IT, and start measuring output of Agile teams by value generated. This will force more rigour on the business case and planning process, and give program managers a much more effective tool to manage priorities from multiple projects.

             
            cheers,
            Robin Dymond




            -----Original Message-----
            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sherri Dotson
            Sent: Friday, February 03, 2006 9:03 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Re: Project Capitalization


            Peter,
            This is great information and it will be great to
            exchange dialogue on your experiences again. : ). 

            We must talk soon.
            Sherri Dotson

            --- pborsella <pborsella@...> wrote:

            > --- In
            scrumdevelopment@yahoogroups.com,
            > "aliciayanik0724"
            >
            <aliciayanik0724@y...> wrote:
            > >
            > > I'm sure this has
            been asked and answered before,
            > but a quick search
            > > didn't
            turn up enough information for me.  I'm
            > looking to
            understand
            > > how other organizations, while using Scrum,
            gather
            > the data
            > necessary
            > > to capitalize projects
            (and pass an audit).
            > >
            >
            > Alicia...the first thing we
            had to do is agree that
            > we needed to
            > record our time purely for
            accounting purposes.
            > This is an important
            > and sensitive matter,
            because we don't want time
            > tracking to be used
            > as an indication
            of productivity.  Next, we worked
            > with our Finance
            >
            department to understand which activities qualify
            > for capital
            and
            > which do not.  So, for example, "development" would
            > be
            a capital
            > activity, but "project management" might not
            >
            qualify.
            >
            > What does "project management" have to do with
            >
            Scrum?  This is the
            > Finance category that we used to account for
            the
            > daily Scrum.  15
            > minutes a day x the number of folks on
            the team x
            > multiple capital
            > projects adds up!  This amount
            of time needs to be
            > recorded so Finance
            > knows how much gets
            capped and how much doesn't.
            > Remember, "project
            > management" is
            an example of a non-capital
            > activity...your Finance
            > dept. may
            have others.
            >
            > So where do you record this?  We don't want
            to
            > interfere with the
            > logging of "what's left" burndown
            maintenance, so we
            > keep the Finance
            > time separate from the
            burndown.  This of course
            > meant that we needed
            > a
            time-tracking tool.  Once you know which
            > activities don't
            qualify,
            > you can then ensure that the time spent on those
            >
            activities get
            > recorded and submitted to Finance.
            >
            > I'm
            trying to explain in a few paragraphs what took
            > many hours to
            >
            devise.  You'll need to spend some time evaluating
            > the best way to
            do
            > what you're asking without violating Scrum
            >
            principles.
            >
            > I hope this helps
            some...Pete
            >
            >
            >
            >


            __________________________________________________
            Do You Yahoo!?
            Tired of spam?  Yahoo! Mail has the best spam protection around
            http://mail.yahoo.com


            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
               
            http://groups.yahoo.com/group/scrumdevelopment/

            <*> To unsubscribe from this group, send an email to:
                scrumdevelopment-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
               
            http://docs.yahoo.com/info/terms/


            
            
            
            
            
            
            The information contained in this e-mail is confidential and/or proprietary
            
            to Capital One and/or its affiliates. The information transmitted herewith
            
            is intended only for use by the individual or entity to which it is 
            
            addressed.  If the reader of this message is not the intended recipient, 
            
            you are hereby notified that any review, retransmission, dissemination, 
            
            distribution, copying or other use of, or taking of any action in reliance 
            
            upon this information is strictly prohibited. If you have received this 
            
            communication in error, please contact the sender and delete the material 
            
            from your computer.
            
            
            
            
          Your message has been successfully submitted and would be delivered to recipients shortly.