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

Project Capitalization

Expand Messages
  • aliciayanik0724
    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
    Message 1 of 5 , Jan 18, 2006
      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).
    • 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 2 of 5 , Jan 31, 2006
        --- 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 3 of 5 , Feb 1, 2006
          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 4 of 5 , Feb 3, 2006
            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 5 of 5 , Mar 2, 2006
              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.