Asset Management: What Types of Assets Might You Manage?
From the Disciplined Agile Blog
by Tatsiana Balshakova,
Mark Lines, Mike Griffiths, Scott Ambler, Bjorn Gustafsson, Curtis Hibbs, James Trott
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.
View Posts By:
Tatsiana Balshakova
Mark Lines
Mike Griffiths
Scott Ambler
Bjorn Gustafsson
Curtis Hibbs
James Trott
Past Contributors:
Joshua Barnes
Michael Richardson
Daniel Gagnon
Valentin Tudor Mocanu
Kashmir Birk
Glen Little
Klaus Boedker
Recent Posts
DA 5.6 is released
Disciplined Agile 5.5 Released
Choose Your WoW! Second Edition Is Now Available
Requisite Agility applied in Project Management
Disciplined Agile and PMBoK Guide 7th Edition
Categories
#ChoiceIsGood,
#ChooseYourWoW,
#ConsumableSolution,
#ContinuousImprovement,
#CoreAgilePractices,
#experiment,
#Experimentation,
#GuidedContinuousImprovement,
#Kaizen,
#LifeCycles,
#ProcessImprovement,
#TealOrganizations,
Adoption,
agile,
agile adoption,
Agile Alliance,
Agile Business Analyst,
Agile certification,
agile data,
agile governance,
agile lifecycle,
agile metrics,
agile principles,
agile transformation,
Agile2018,
Agile2019,
Agile20Reflect,
AgileData,
Analogy,
announcement,
Architecture,
architecture,
architecture owner,
Articles and publications,
Asset Management,
Atari,
Backlog,
Barclays,
being agile,
benefits,
bi,
blades,
book,
Branching strategies,
Browser,
Business Agility,
business intelligence,
business operations,
capex,
Case Study,
Certification,
certification,
charity,
Choose your WoW,
CMMI,
cmmi,
Coaching,
Collaboration,
Communications Management,
Compliance,
Compliancy,
Conference,
Construction,
Construction phase,
Context,
Continuous Improvement,
coordination,
COVID-19,
Culture,
culture,
Cutter,
DA,
DAD,
DAD Book,
DAD discussions,
DAD press,
DAD roles,
DAD supporters,
DAD webcast,
DADay2019,
Data Management,
database,
dependencies,
Deployment,
Development Strategies,
DevOps,
disaster,
Discipline,
discipline,
Disciplined Agile,
disciplined agile delivery,
disciplined agile delivery blog,
Disciplined Agile Enterprise,
disciplined devops,
Documentation,
Domain complexity,
dw,
DW/BI,
Energy Healing,
Enterprise Agile,
Enterprise Architecture,
Enterprise Awareness,
enterprise awareness,
Essence,
estimation,
Evolving DA,
Executive,
Experiment,
facilitation,
FailureBow,
feedback-cycle,
finance,
Financial,
FLEX,
Flow,
foundation layer,
Funding,
GCI,
GDD,
Geographic Distribution,
gladwell,
global development,
Goal-Driven,
goal-driven,
goals,
Governance,
GQM,
Guideline,
Hybrid,
Improvement,
inception,
Inception phase,
India,
information technology,
infosec,
Introduction,
iterations,
Kanban,
large teams,
layer,
lean,
Lean Startup,
learning,
Legal Project Management,
LeSS,
Lifecycle,
lifecycle,
Manifesto,
mark lines,
marketing,
MBI,
Metaphor,
Metrics,
metrics,
mindset,
Miscellaneous,
MVP,
News,
News and events,
Non-Functional Requirements,
non-functional requirements,
Non-solo development,
offshoring,
Operations,
opex,
Organization,
Outsourcing,
outsourcing,
paired programming,
pairing,
paper,
People,
People Management,
phases,
Philosophies,
Planning,
PMBoK,
PMI,
PMI and DA,
PMI Chapter,
Portfolio Management,
post-format-quote,
Practices,
practices,
Principle,
Process,
process improvement,
process tailoring,
Product Management,
product owner,
Product Owners,
productivity,
Program Management,
Project Management,
project-initiation,
Promise,
Quality,
quality,
rational unified process,
Refactoring,
Reiki,
Release Management,
release management,
Remote Training,
Remote Work,
repeatability,
requirements,
Requirements Management,
research&development,
responsibilities,
retrospectives,
Reuse,
Reuse Engineering,
ride for heart,
rights,
Risk Management,
Risk Management,
Risk management,
Roles,
RUP,
SAFe,
sales,
Scaling,
scaling,
scaling agile,
Scheduled Workshops,
SCM,
scorecard,
Scrum,
ScrumMaster,
SDLC,
Security,
security,
self-organization,
SEMAT,
serial,
skill,
solutions software consumable shippable,
Stakeholder Management,
strategy,
Support,
Surveys,
Teal organizations,
team development,
Team Lead,
team lead,
Teams,
Technical Debt,
Teleconferencing,
Terminology,
terraforming,
test strategy,
testing,
time tracking,
Tool kit,
Toolkit,
tools,
traditional,
Transformation,
Transition iteration,
transition phase,
Uncategorized,
Upmentors,
Using PMI Standards,
value stream,
velocity,
vendor management,
Virtual Training,
Workflow,
workflow,
workspaces
Date
When we think about assets we often think "financial assets" such as money, stocks, bonds, and other financial instruments. But of course there are many more types of assets than just financial ones, particularly when we consider it from the point of view of our organization.
We are currently in the process of evolve Disciplined Agile (DA)'s Reuse Engineering process blade, which had a very clear software focus to it, into a more robust Asset Management blade. Part of that effort is to rework the reuse categories, which we had originally adopted from the Enterprise Unified Process (EUP), depicted in Figure 1 into the asset categories of Figure 2.
Figure 1. Categories of reuse.
Figure 2. Categories of assets.
As you can see, we've made several interesting changes:
- We've gone far beyond software. There are many different types of assets that can be made available for reuse, not just software. To be fair, as you can see in Figure 1 we did in fact go beyond software reuse but the focus was still on IT/software-oriented assets.
- Introduced the concept of tangible and intangible assets. Tangible assets are things that you can touch, things that are made from atoms. Intangible assets are concept, made from bits or in some cases stored in neurons. Asset management needs to address both of these asset classes.
- Reduced the number of categories. We went from seven to five categories so as to simplify the overall approach.
- Adopted flexible categorizations. We realized that the definition of the categories, in some cases, would vary given your context. For example, we've indicated that a vehicle might be both a component and a large-scale component. If you're a car rental agency then a vehicle is a component of your overall fleet. If you build cars then a vehicle is a large-scale component built from smaller components.
We'd love to hear your feedback, particularly if you have ideas to improve Figure 2. Looking forward to reading your comments below.
Posted
by
Scott Ambler
on: February 02, 2021 02:22 PM |
Permalink
Comments (5)
Please login or join to subscribe to this item
It might be interesting to see how many of the well established ideas from traditional (i.e. physical) asset management (e.g. pumps, factory machines) frameworks can be incorporated "as is" into this process blade...
Scott Ambler
Consulting Methodologist| Ambysoft Inc.
Toronto, Ontario, Canada
Yes, we're investigating that right now. The most interesting issues still tend to be on the intangibles side, although tangibles have their moments. ;-)
Kwiyuh Michael Wepngong
Community Champion
Financial Management Specialist | US Peace Corps
Yaounde, Centre, Cameroon
Hi Scott,
You aid it and very correctly, that
"...There are many different types of assets that can be made available for reuse, not just software..." Asset management becomes interesting when you've to manage a plethora of these asstes in the categories of New aquired, Used, Reused and so on
Perfect.
Thanks for sharing
Dear Scott,
Thanks for sharing your thoughts on this interesting topic.
I agree that reusing engineering can be beneficial and cost-effective if the organization chooses the appropriate assets to reuse in a supportive and collaborative environment. For example, a project implementation methodology created for a particular product can be categorized as a valuable reusable asset.
However, when it comes to reusing codes, which you mentioned multiple times in your webinar, I’m afraid that I disagree with you. In my opinion, it is an impractical and misleading tactic.
First, a consumable software solution in most cases is built upon an existing foundation as an expansion of the program. It can be complicated to split and identify the sets of codes and only copy the needed parts. Most likely, such practice will only result in a paralyzed clone instead of a drivable vehicle, squandering the organization’s time and money.
Secondly, a consumable solution is much more than a set of codes. The software serves as a tool that runs in tandem with defined business processes in an enterprise environment to achieve the desired business results. Blindly copying the codes is like installing a V8 engine in a SMART car that runs in Paris without changing any other parts or validating the environment. It is a waste of time and effort; it will disable the car in a worst-case scenario.
Finally, from a technical point of view, different software can be written in other languages operating on different platforms/infrastructures. Sometimes a team wrote codes to work around the constraints or fully utilize the technological strength, rendering the reusing case implausible.
In summary, we can reuse high-level assets such as artifacts but must be highly wary when reusing codes. Resist the illusion of fast delivery through copying codes, an attractive but deadly route.
Please let me know your thoughts on this.
Thanks and regards,
Amanda Chen
Please Login/Register to leave a comment.
|
"When angry, count to four; when very angry, swear."
- Mark Twain
|
