Author Archives: Frank SAPAA

Unknown's avatar

About Frank SAPAA

Webmaster and Board Member of SAPAA and born and raised Albertan. Love exploring Alberta particularly in the winter on snow shoes.

Is this Bespoke Spoken For?

Posted on by
Reply

It is a truism to say that organizations, in particular governments, are relying more and more on technology to operate and deliver services.  In a 2014 blog, IM/IT Inventory, I explored the concept of what assets should an organization actively manage and track.  The following graphic was introduced as part of a larger concept known as the IM/IT Lifecycle.

IM/IT Inventory-Model with sample mappings

To Include or Not to Include – that is the Catalog?

The purpose of the blog series was to try to answer the question, which bit of technology should be included, or not, in things like an inventory of applications.  The conclusion was pretty much, if it has value – include it – and if it will take a material amount of effort to recreate it, definitely include it.

Alas there is a definitional challenge when it comes to building application catalogs, namely WHAT IS an application?  Some definitions available include:

  1. ITIL – Application: Software that provides functions which are required by an IT service. Each application may be part of more than one IT service. An application runs on one or more servers or clients. See also application management; application portfolio. (Axelos.com; glossary, accessed 2018-01-27).
  2. COBIT – Application: A computer program or set of programs that performs the processing of records for a specific function.  Scope Notes: Contrasts with systems programs, such as an operating system or network control program, and with utility programs, such as copy or sort. (www.isaca.org; glossary, accessed 2018-01-27).
  3. Techopedia – Application software is a program or group of programs designed for end users. These programs are divided into two classes: system software and application software. While system software consists of low-level programs that interact with computers at a basic level, application software resides above system software and includes applications such as database programs, word processors and spreadsheets. Application software may be grouped along with system software or published alone. Application software may simply be referred to as an application. (www.techopedia.org, accessed 2018-01-27).

Why Ownership Matters

All 3 definitions try to get their arms around the question, how long is a piece of string.  Unfortunately the string is only going to get longer as applications pop up on smart phones, are meshed with AI or are used by an organization but inhabit the cloud.  Nevertheless, the definition is important because no matter where/how/who etc. the application is run – an organization must still keep internal accountability for its creation, maintenance, usage, information management and ultimate disposal.

Accountability is important because if service is increasingly delivered by technical means (including robots, AI, cloud and the Borg) then human accountability for its proper functioning and adherence to business objectives becomes more, not less, important. 

Another important reason to define an application is to provide ownership both technical and business.  This concept will become both more difficult and more important as applications become completely embedded in business processes and wink in/out of existence because of an accelerated development time frame.

But is ‘IT’ Spoken For?

One of the challenges of trying to assign ownership is that busy business users don’t want to be bothered with having to own technical resources such as a flux capacitor or an anti-matter chamber (these exist, right?).  They want to focus on their widget production system without being bothered with tech-esse.  However, all the technical bits need to be ‘owned’ by someone for no other reason than to ask: ‘can we turn it off‘?  To assist with this, I am proposing a 3 tier ownership structure.

Level/Description Typical Owner Examples
1. Strategic.  Technology in this group is often at the system level meaning that it is composed of 2 or more applications.  A strategic system is often long-lived and may directly or indirectly support multiple areas of the organization and product lines. The most senior person in an organization that relies on the technology for their immediate accountability.  Resist the urge to give everything to the President/CEO – this is the day-to-day senior owner, e.g. the VP of Operations.

The owner may sometimes be known as the information controller.  I like this as it focuses on the value of a system (information) rather than the means of a system (technical).
  • ERP system including manufacturing, inventory, sales, etc.
  • Production or product support system
2. Tactical Application. A bit of software that may support one or more business/technical needs.  Each tactical application has a single or a few outputs it produces.  It may exist on its own and/or it may be part of a larger system. Because most entries in an organization’s application catalog fall into this category, it is not surprising that most owners are middle level managers.

The biggest challenge in this category is what is in or out.  See the above blog for some thoughts on this.
  • Speciality reporting tools for finance/ marketing.
  • Stand alone database to track a single business function.
3. System/Operations. A bit of software that the techies are primarily aware of… until it does not work of course.  This includes ITIL system programs but may include utilities that business users rely on to operate a tactical application. Although these applications support a business user, their owners are the technical folks.  In this way, the technical areas provide a service to the business/ tactical applications.
  • Print utility, payment control system integrated with a bank, network or firewall software.

Like most things in life there are definite grey areas between the above 3.  This is where professional judgement comes to assign a bit of code to the right category and therefore to the correct accountable person. In doing the assignment, I would suggest that an organization use the following rubric in assigning ownership.

  1. Start High – Work Low: there is an inclination to make all technical things belong to the techies.  Therefore, all systems start with being owned by the highest possible level until they are pushed down based on the following guidelines.
  2. Who Gets to Change or Turn IT Off: this guideline is the contrary to the above, who gets to make changes to the bit of software.  Ideally this should be pushed down as low as possible.  When in doubt, who is responsible to to turn the dang thing off when the application has outlived its usefulness.
  3. The User/Customer, Disenfranchised and the Veto: Because the first two purposely try to move ownership either up or down an organization, the last consideration is consider the outcome.
    1. Who is nearest to the user/customer of the bit of software and therefore can make the best determination whether or not cinnamon red on a burnt orange background is a good colour scheme for web page. Move ownership down when this factor is important.
    2. Who are the internals and externals who are affected but are disconnected from the decision-making choice; these may be users or a few degrees separated from the user. Move ownership up when this factor is important.
    3. Who has a veto either explicitly or implicitly?  What are the internal and external politics of the bit of software?  If there are few such considerations, move ownership down; if there are many such considerations, move the software up.
  4. The Times are a Changin’: Use professional judgement to make a determination and then plan to periodically or ad hoc return to the decision.  Hopefully ownership generally moves down as a system matures and becomes stable – a change in the environment may require it to go up for a bit..

Conclusion and Other Ownership Constructs

The above takes a bit of a traditional view of ownership and purposely avoids such knotty issues as open source software or software as a service.  My expectations is that an organization with lots of applications to document (in particular governments) should spend time on these assets and then turn their attention to the more esoteric.  If an organization really does not own any applications then this discussion is a bit mute and academic anyway.

Let me know if the above model is useful and how you would improve it!

 

 

Against the Gods

Posted on by
Reply

Peter L. Bernstein wrote “Against the Gods: The Remarkable Story of Risk” in the late 1990s, well before the financial meltdown of 2008 or the dot come bubble burst a few years later. The book itself is a good refresher of the history of mathematics and provides a reasonably entertaining and well written history of risk.  Before getting to the book though, a quick detour about Bernstein himself.

A Life Well Lived

Bernstein died in 2009 at the age of 90.  Over those nine decades he was born into relative wealth, served as an officer in World War II, worked for the US federal government, taught university, took over his father’s investment business, sold the business for a tidy sum, wrote ten books – 3 in his late 80’s and became a respected academic.  WHEW

For anyone of us, a few of the above accomplishments in our lifetime would be gratifying (including making it to 90) let alone the number he accomplished.  In other words, Bernstein can be said to have had a life well lived.

The Good News from the Gods

Some of the reviews on http://www.goodreads.com have critiqued Bernstein’s writing style.  It is not the most elegant I have ever read but it was reasonably engaging and not too technical.  He takes a chronological approach to risk but this is really on the mathematics of risk.

He notes the restrictions early western mathematicians had including the Roman numeric system, the enlightenment and renaissance (to get beyond the notion that all things are pre-ordained by God), bookkeeping, forecasting, algebra and an unfinished game of chance.

To this last point, the question was how best to divide up the winnings of a game with a fixed number of iterations of the game that was partially played.  This question spurred the mathematics to ask the question about probabilities and the future.  Risk management was born.

From the renaissance, Bernstein takes us through the development of more advanced mathematics, game theory and then finally the rise of the Quants in computerized trading.

In other words, the book is a good and reasonably accessible refresher on the history of mathematics and specifically the development of statistics and financial mathematics.  Bernstein does explore some of the human side of risk.  For example he discusses those old favorites of behavioral economics: loss aversion, regression to the mean / Prospect Theory, ambiguity aversion, etc. In other words, a good historical romp that ties in some familiar and some unfamiliar details into a reasonably good overview of the mathematics of risk…

The Bad News about the Gods

… and therein lies the biggest problem with the book, big on math short on the story of risk.  There is so much more that Bernstein could have incorporated into the book.  For example

  • How is risk perceived and managed in different cultures.
  • How have the Christian and Muslim beliefs about risk and interest rates changed their respective trajectories.
  • What has been the impact over the past 50 years on risk management given that risk has now being overtly managed.
  • How have institutions such as the military, healthcare or pharmaceuticals changed in how they managed risks.
  • What was the impact of large-scale events on the acceptance and management of risk, for example did the Black Death make people more or less risk averse and how did this affect risk management.

In a way it is too bad that Bernstein wrote the book when he did or that he did not write it say 10-12 years later.  I would have been interested in his views on the 2008 financial crisis and the work of Nicholas Taleb, etc. who also discussed risk, statistics and randomness.

In the End

So, a good read if you enjoy history, mathematics and what a fuller understanding of the concepts of risks.  A revised edition would be great, or even better, a second volume with more depth and breadth.  Never the less a read that rounds out anyone interested in Risk Management.

A few Quotes and Thoughts

Publisher’s Description: With the stock market breaking records almost daily, leaving longtime market analysts shaking their heads and revising their forecasts, a study of the concept of risk seems quite timely. Peter Bernstein has written a comprehensive history of man’s efforts to understand risk and probability, beginning with early gamblers in ancient Greece, continuing through the 17th-century French mathematicians Pascal and Fermat and up to modern chaos theory. Along the way he demonstrates that understanding risk underlies everything from game theory to bridge-building to winemaking.

p. 15: Time is the dominant factor in gambling.  Risk and time are opposite sides of the same coin, for if there were no tomorrow there would be no risk.  Time transforms risk, and the nature of risk is shaped by the time horizon: the future is the playing field.  Time matters most when the decisions are irreversible.

p. 197: The essence of risk management lies in maximizing the areas where we have some control over the outcome while minimizing the areas where we have absolutely no control over the outcome and the linkage between effect and cause is hidden from us.

p. 228: Keynes argued that interest is a reward for parting with liquidity, not for refraining from consumption.

p. 232: Game theory says that the true source of uncertainty is in the intentions of others.

 

PRMM – How is That Planning Thing Working Out for You?

Posted on by
Reply

This is the second in a series of blogs on a Practical Risk Management Method or PRMM.  At the bottom of this blog is a refresher of the other steps.  This step’s premise is don’t separate your planning activities from your risk management activities.  In other words:

Planning = Risk Management. Planning is ultimately about managing uncertainty which is a fancy name for Risk.  At this point you may be saying:

  1. Of Course: we already do this. Good on you, see you at the next blog!
  2. Great Idea: this may be incrementally more work during the planning process but ultimately over all less effort for the organization.
  3. What is This Planning Thing you Speak Of: hmmm, we may have identified your top risk.

I am afraid I can’t help you if you fall into the last category but hopefully these blogs can help you if you with the first two.

Continue reading →

Practical Risk Management Model

Posted on by
1

Is traditional risk management practical?  If so, why do so many organizations struggle to do it well?  As a quick refresher here are the three steps of virtually all risk management methods:

  1. Establish business objectives.
  2. Identify and quantify some or all of the risks that may prevent the organization from achieving these objectives.
  3. Figure out what you are going to do with the resulting risks (e.g. ignore, manage, transfer, assign owners, etc.).

An Practical Risk Management Method (PRMM)

What makes risk management impractical is that it is often a bolt on and/or a parallel activity.  In addition, risk management often gets bogged down in too many risks and not enough value add (see my blog “Guns, Telephone Books and Risk?” for more on this).  PRMM recommends the following steps:

  1. Planning = Risk Management. Incorporate risk management into existing operational, tactical and strategic planning; don’t separate the two.  Why?  Because planning is how organizations manage uncertainty which is a fancy name for Risk.
  2. Are You Any Good at Change? Evaluate how well your organization responds to change (e.g. when uncertainty becomes certain).  When the unexpected happens, was your response chaotic and uncoordinated or did it go more or less to plan?
  3. How Strong is your ARM? ARM or Antifragile Risk Management is a system that focuses on building robust and resilient organizations.  While step 2 above measures the organization in action, this step anticipates your organization’s uncertainty resiliency.
  4. A Certain Test of Uncertainty.  The organization’s risk/opportunity log is used to stress test the work done above.  Testing measures the robustness of the organization and the scope and reasonableness of the collected risks.  This is the traditional risk management step in PRMM.
  5. Don’t Stop. Modify/improve your plans and keep going.  All of the above activities are meant to be both periodic (e.g. the annual planning process) or continuous.

My next blog are some thoughts on step 1 above, integrating risk management into the planning processes of the organization.

Enterprise Risk Management – And a bit of Sales

Posted on by
Reply

In my ongoing effort to remember what I read, a few notes about a book on Enterprise Risk Management: Mastering 21st Century Enterprise Risk Management: Firing Dated Practices | The Best Practice of ERM | Implementation Secrets; by Gregory M. Carroll. 

Full Disclosure: Fast Track Founder

Before going any further, the book is written by the founder of an Australian company, Fast Track, which sells ERM and compliance software.  On the one hand there is a bias in the book toward the software.  On the other hand, EXCELLENT!, the company has been thinking about ERM for more than 30 years, who better to comment.

The ERM I Was Expecting

I have been on the periphery of the Risk Management Biz for most of my career and it never impressed me very much.  It seemed like a bolt on activity to compile a ‘telephone book‘ of risks that would never happen.  Worse, risk management takes precious management and organizational time away from operations which ironically increases risks.  This is not to discount the value of risk management though and having mitigation plans for many of the likely scenarios (hacks, robberies, natural disasters, etc.).  Starting with mitigation is why I wrote the blog series on ‘Anitfragile Risk Management (ARM)‘.

This book is short (about 80 pages) and has some good practical advice on ERM.  I would not buy the full version but definitely take a good skim/read via your public libraries online services.  The following 5 items are my key takeaways from the book; there are more but these are ones that I will likely return to a few times.

  1. Risk Management in 30 Seconds.
  2. Acknowledgement that Risk Management is a Dark Art
  3. The Nature of Risks
  4. Risk Management is Really Opportunity Optimization
  5. Ten Rules for a Successful IT Project

Carroll presents a vision or ERM that is much closer to my view of ARM… to a point.  So notes on the great points he makes in his book and the limitations of thinking about risk management when you are in the business of selling ERM systems (these editorial comments are in italics).

Risk Management in 30 Seconds

In ten paragraphs, Carroll runs through what is Risk Management, the summary of the summary is as follows (pp 4-5):

  1. 00:00 Definition: The level of uncertainty in any situation. Risk management is a system that identifies, quantifies and attempts to reduce or eliminate uncertainty.
  2. 00:25 Identification: ERM starts with a set of corporate objectives covering all aspects of the enterprise’s intents. Understand organizational risk appetite: the level of risk that can be tolerated on an on‐going basis.
  3. 01:00 Assessment: A subjective and preventive evaluation of each uncertainty in a specific area of operation by internal subject matter experts. A risk matrix grades the impact of a risk based on likelihood of it happening and the effect (consequences) if it does.
  4. 01:40 Control: A control is an action or measure that can alter an uncertainty.
  5. 02:00 Mitigation: Mitigation is a fancy word for an action that reduces or eliminates a risk.
  6. 02:45 Review: Review is value add and facilitates continual improvement.

This is a good overview and is entirely consistent with ISO 31000.  Carroll’s point in this section is that risk management is not especially difficult and that a simple framework can help you.  The ARM methodology turns the above 3 minute overview on its head however and places review and mitigation first and the other activities subordinate to these value add functions. 

Acknowledgement that Risk Management is a Dark Art

Carroll describes risk management as being 80% Art and 20% science (p. 12).  This is part of his view that organizational change and people management are central to an effective ERM systems.

Carroll is on the right track here but I would change his allocations slightly.  I would put the Art part as being 90%, the Process Changes as being 9% and the ERM system itself as being 1%.  Risk/Opportunity management is primarily a state of mind that is dependent upon trust, adeptness, competence of people.  An ERM without this is doomed to failure, an organization with these attributes already has an ERM system.

The Nature of Risks

Carroll differentiates between the ‘Nature of Risk’ and the ‘Types of Risk’.  Nature is a higher level classification that groups risks conceptually; how the risk presents itself and how it is subsequently managed (p. 13); they are as follows:

  1. Technical Risks are the broad group of risks whose state can be measured discretely and against which quantitative limits can be set and monitored. They are caused by variations that affect the system and are managed through use of mathematical models.
  2. Operational Risks are around the internal operations of a business, predominantly dealing with people, processes and systems and what most people think of in enterprise risk management.  Qualitative by nature, they tend to be caused by changes to organisation or behaviour, and are managed though process management.
  3. Security risks are aggressive actions. They are intentional in nature, as opposed to other categories which are consequential in nature. They are premeditated attacks which are managed proactively through surveillance and defensively though multi‐layered safeguards commonly refer to as “defence‐in‐depth”.
  4. Black Swan events are events in human history that were unprecedented and
    unexpected at the time they occurred. These once‐in‐a‐lifetime events are
    unpredictable, occur abruptly and catastrophic in nature.  Being unpredictable and occurring abruptly, the risk itself cannot be managed in a traditional sense, so we have to manage its effects using such methods as disaster planning and relief strategies.

Carroll acknowledges that the four presented are not meant to be exhaustive.  Nevertheless, this is a much better starting point than an exhaustive ‘type of risk’ listing.  The challenge I have seen with such lists is that very quickly organizations get bogged down into definitional quagmires.  The above list can be thought of as having multiple dimensions, for example internal or external to the organization.  

Risk Management is Really Opportunity Optimization

ISO 31000 focuses not on risks but on uncertainty which may be positive or negative to an organization.  Carroll’s book is generally upbeat about both although most of his examples end up being of negative variety versus positive.

This upbeat note extends into systems implementations.  Obviously his frame of references is for implementing an ERM system but his words of wisdom could be as easily applied to an ERP or other corporate system.  Nothing new here but still a good refresher:

  • People: The employees, managers, customers and other stakeholders.  In particular, what motivates your employees and how can you align a project to these motivations to be most successful.
  • Change Management: A project is not about the technology it is about how people will work once the project team has long gone.
  • The System and the Project: Lastly, how the project and system will be implemented and then used to support the above.

Ten Rules for a Successful IT Project

  1. Don’t outsource requirement planning.
  2. With software vendors, big is not necessarily best (Note, I think there is some bias here on the part of Carroll toward his software and away from the larger systems; this bias may be entirely justified but full disclosure nevertheless).
  3. Choose a ‘people’ project manager.
  4. Have a living risk management protocol.
  5. Ensure all stakeholders have “skin” in the game.
  6. Use an agile implementation technique.
  7. A quick game is a good game.
  8. Plan your testing.
  9. Training – Sell the benefits.
  10. Treat as a change-management issue not an IT project.

https://www.linkedin.com/in/gregorymcarroll

ASK-ACTION Emails

Posted on by
Reply

Have you ever gotten one of those rambling emails in which the request is buried somewhere in a sea of asides? Given that it is from your boss, you press on trying to divine what the &%#@^ she is asking for! (note, all examples are fictional and any resemblence between current and past bosses and this example is purely coincidental).

Alternatively, you receive an email that clearly articulates its purpose in the first two lines and a quick scan tells you what to do or even whether it is applicable to you. If you would rather receive (or send) the second type of email, read on to learn about the ASK/ACTION format.

What are you ASKing of me?

An ASK/ACTION Email looks something like this:

Ask-Action Email Format

The Elements of an ASK

There are four parts to an ASK/ACTION email that help to make it clear:

  1. SUBJECT:  that provides a summary and the deadline.
  2. ASK: What is the context for this email.
  3. ACTION: What do the recipient(s) need to do; a clear statement of what needs to be done, by whom and by when.
  4. BODY: Additional details as applicable.

After the two liner, additional information is provided to flush out the request.  Nevertheless, this is the ASK/ACTION email format.

Bonus Points and Additional Links

Some other thoughts and suggestions when using an ASK/ACTION email:

  • If you are using the Lost Assignment and Task Epidemic methodology, consider using the TASK name in the subject line.
  • Send one email for one ASK/ACTION; apologize though and note if multiple emails are coming through.
  • Personalize your emails if possible.
  • For group emails, consider following up with a short conference call to explain the ask, this allows for more than one channel of communication.
  • Send a meeting invite out as a reminder only, thus the above email would be converted to a meeting with a location of ‘Reminder Only’ for 2099-12-31 at 4pm.
  • Use the BCC to reduce email churn but notify people at the beginning, for example: You have been BCC’d to protect your privacy.
  • If you are including documents but have a shared repository (e.g. network drive, SharePoint, etc) note that there is a courtesy attachment but specify the master version with a link: Master Version: M-Drive:2098-2099\Analysis\HelpMe\.

Some other links and thoughts on this:

Citizen Centeric Experience – PwC Event 2017-11-24

Posted on by
Reply

In my ongoing effort to remember the key notes from events and conferences I have attended, some thoughts on Rethinking the Customer/Citizen Experience; 2017-11-24.  The overview blurb was:

We will look at transformation through the lens of both the ultimate end-user experience, and the internal employee perspective which inherently must be connected to successfully implement change.

Personas and Small Things Create Big Results

Two key themes that came out of the event.  The first was the use of personas to aid in develop a good customer experience.  The second was the importance of implementing big things through a series of small steps.

Personas

Developing a persona is an attempt to understand behaviors of customers/clients.  These are done to help frame development and make changes.  The recommendation is to limit the number of personas to less than six and ideally 3-6.  A single persona is then used to track a collective journey through a process journey.  One description of a persona is as follows (Adapted from Agile Modeling):

A persona defines an archetypical user of a system.  The idea is that if you want to design effective software, then it needs to be designed for a specific person. Personas represent fictitious people which are based on your knowledge of real users. Unlike actors, personas are not roles which people play. In use case modeling actors represent the roles that users, and even other systems, can take with respect to your system. Actors are often documented by a sentence or two describing the role. Personas are different because they describe an archetypical instance of an actor. In a use case model we would have a Customer actor, yet with personas we would instead describe several different types of customers to help bring the idea to life.

It is quite common to see a page or two of documentation written for each persona. The goal is to bring your users to life by developing personas with real names, personalities, motivations, and often even a photo. In other words, a good persona is highly personalized. 

Personas and the Public Sector

According to PwC, personas have been used successfully in various public sector organizations including the Canadian federal government.  My Spidey-risk-senses however went up over two aspects:

  1. The volume of the personas.  Governments do things that no one else wants to do, given the myriad of our product lines; can we realistically develop personas for the breadth of services provided?
  2. Personas as a Cause Celebre. What is the risk of personas becoming a political nightmare? Our society has become increasingly sensitive and intolerant to labels. What are the risks of not having the right personas to meeting a groups demands or having to remove a persona because it does not match an external groups political objectives?

Personas But Tread Carefully

The answer is to use personas but create them through engagement with those they represent. As well, some political mettle is likely required to explain to role of a generic persona that provides a model or analog to society at large (heck, is this not the description of a representative democracy!). Nevertheless, have an emergency risk mitigation plan for either the creation of politically mandated personas or for suppression/modifications of personas for similar political imperatives.

Other than these risks, using a customer experience focused technology methodology can be highly applicable to the public sector. Like most things though, the proof is in the execution and delivery. This leads us to the second part of the morning’s presentation –

Small Steps to Implement Big Change

I am a big fan of the Agile method (e.g. small successes building over a few weeks to a larger objective) versus waterfall.  My observation for governments though is that the larger organization has a hard time with Agile.  It is easier to understand and support a multi-year, multi-million dollar project (e.g. put a man on the moon by the end of a decade) than approve the objective but in a series of short sprints (e.g. what do you mean you plan to have 520 sprints to get a man on the moon!).

Of course I am not being entirely fair to governments in saying this.  After all, it was Apollo ELEVEN that landed on the moon, Apollos ONE through TEN were examples of very LARGE sprints. Nevertheless, here is my thinking about any project:

  1. Large objectives are fine (moon, replacing an aging system, etc.)
  2. The objective must be broken into a series of steps (phases, projects, etc.)
  3. Each step in turn should not exceed the following:
    1. Six months in length
    2. $500,000 in expenditure
    3. 25 people for the entire project team.
    4. Only start upon the successful completion or closure of a prior step.
    5. Turn over is limited but also encouraged, e.g. no more than ~90% of the team is the same project to project but no less than ~50% of the team has changed.
  4. The above measures can be an average for a system, thus
    1. Subsequent phases can get larger but only after smaller projects have successfully concluded
    2. Professional judgement and risk tolerance is encouraged so that the above is a strong guideline and not a set of absolutes.

 

 

 

2017 – Phranks Professional Development

Posted on by
Reply

As an accountant, I am both proud and obligated to report my Continuous Professional Learning and Development (PD).  The following are my calendar year 2017 activities which total more than 300 hours (which does not included are some of my social activities such as cycling and snowshoeing).  I have no problem making these as a public declaration given that accountants serve the public.  Within the comments field I will include the learnings, whether it is verifiable or not (e.g. I have a bit of paper to prove that I was there).

Date Event Time (Hours) Comments
2017 Awards and Nominations 20 Member of CPA Alberta awards and nominations committee.  This included attending meetings (~10 hours), reviewing and managing submissions (~20 hours) and developing future plans to improve public sector participation (see the blog series of the same topic).
2017 FMI – Disruptive Writers 100 Although I am only claiming 100 hours, this was actually about 200 hours of effort.  Nevertheless, some great learnings from this event including:
Sep 19 FMI – Lost Dutchman’s Mine 3 Attended and supported its promotion and planning.
July/ Aug Attended and participated in the GoA ERP planning sessions 5+ days for ~10 hours – Learned best practices of supply chain management.
– Participated in planning sessions for the GoA.
improved facilitation methods.
Jun 22 Forrester Briefing – Digital Transformation: Charting a Digital Strategy in the Age of the Citizen 2 Breakfast meeting with the topic of:Technology has mobilized citizens with information and access power they’ve never had before. That changing expectation compels government agencies and organizations to transform to meet their needs.  Attendees will: – Master digital’s new rules. – Learn how to differentiation through digital innovation. – Identify the technologies to transform your digital experiences and operations.
Jun 6 FMI Planning Session 2 Facilitated a planning session to establish the next year’s programming for the Edmonton Chapter.
May 17 GoA: Management Engagement Sessions 2 Facilitated session on employee engagement, management’s role and the GoA employee engagement program.
May 17 FMI: Building a Healthy Workplace 120
Apr 12 Public Institution Cyber Security Protocols Working Group Session 6 Facilitated and attended this work session between the Ministry of Advanced Education and Alberta’s post secondary institutions.  Focus was on how to harden cyber security.
Mar 30 CPA Alberta – Get Connected 2017 2 Attendance at the CPA Mixer between employers and new and existing CPAs.
Feb 26 Public Sector Certificate Level 1 40 For my thoughts on this program see my blog of the same name.
Feb 14 First Look at Microsoft Dynamics 365 2 Presentation by Sierra Systems providing an overview of Dynamics 365 technology.  Held at the Glenora Club.
Feb 9 The Alberta Economy – Between a Budget and a Hard Place 10
  • Attendance (3 hours).
  • Support the development of the pre-conference notes via my interns (Cox and Kaur).
Jan 31 People Leader Community Network – Info Session 1
  • Internal Advanced Education training session on leadership and sharing common methods among management.
 Jan 24 Field trip to Treasury Board and Finance 2
  • What is the role of TBF-Finance relative to the GoA finance function (e.g. inter-units, leadership, etc.)
  • What are some of the issues TBF has in consolidations, preparation of statements, etc.
  • What would a career look like in a corporate agency such as TBF for a new CPA
  • A demonstration of IBRS and how it helps to keep the TBF GL clean particularly through the RIA Module.
  • What is the role of the TBF budget team relative the ministry.
  • What challenges and advantages does your team have in preparing the Ministry budget relative to AE.
  • Discussion on your career trajectory and how a CPA helps you in your budget role.
  • Demonstration of your coolest Budget thing you are currently using
  • What role does a controller play in the GoA
  • As an overview, how are the GoA Financial statement consolidated and what are the issues and challenges of doing so
  • What projects does the controller office have underway that may affect AE finance/itm
  • What would a career look like in a corporate agency such as the controller’s office for a new CPA
 Jan 18 Blockchain Innovation Session #2 2 The role of block chain currently and in the future within the public service.  Presentations by PwC and current users.
322 Total Hours

2017-12-03 EBTC Highlands-Beverly Walking Tour

Posted on by
Reply

These are some notes from a December 3, 2017 historical walk I did for the Edmonton Bicycle and Touring Club.  This was a combination of a stroll, historical and social notes.  See my sources below if you want to read more.

Context: The Area pre-1914

  • The area was annexed by Edmonton in 1912, and “was named in a contest offering a 50-dollar Gold Bar.” [1]
  • The neighbourhood is bounded on the north by 118 (Alberta) Avenue, on the east by 50 Street, on the west by 67 Street, and on the south by the North Saskatchewan River valley. [2]
  • The community is represented by the Highlands Community League, established in 1921. [2]

The Walk

Points of interest and route

  • 01) Start: Highlands Community Centre, 6112-113 Avenue, Edmonton.
    • What was the area like at different epochs: 10,000 years ago, pre-Hudson Bay Company, HBC era and then in 1900.
  • 02) South to 112 Avenue; be careful crossing 112th street, look both ways for street cars… the last one ran in 1951 but they could start-up any time! [3]  The end of the line was at 112 Avenue x 61 Street [4].
    • The development of the area was predicated on a street trolley being built.
  • 03) Walk to 6229 111 Ave NW; the Carriage House; this is where they stored the carriages! [1, pp. 267-269].
  • 04) Walk to 6240 Ada Blvd; this is the mansion for Magrath, one of the two developers [1, pp. 257-259].
    • Lived with his wife Ada… notice a connection?
    • And their son Adrian.
  • 05) Walk to 6210 Ada Blvd NW, Holgate Mansion [1, pp. 259-260].
  • Walk along Ada Blvd East towards 50th Street.
  • 06) 50th Street, start of the Beverly Heights Neighbourhood.
    • Originally part of the Town of Beverly, amalgamated with Edmonton 1961. [5]
    • Edmonton assumed the town’s debt of $4.16 million debt ($34.0 million today).[6]
    • The neighbourhood is bounded on the south by the North Saskatchewan River valley, on the north by 118 Avenue, on the west by 50 Street, and on the east by 34 Street and 36 Street. [5]
    • Beverly incorporated as a village on March 22, 1913 and became the Town of Beverly on July 13, 1914. [6]
    • Beverly was a coal mining community that overlooked the North Saskatchewan River valley. During the first half of the twentieth century, more than 20 coal mines were active in and around the town. The larger mines provided much of the town’s employment. [6]
    • In 1907, construction began on the Clover Bar Bridge. The Grand Trunk Pacific Railway (GTPR) built its own bridge as it could not use the CPR High Level. [6]
    • The GTPR became the biggest shipper of coal in Alberta, with much of the coal mined in and around Beverly. [6]
    • The Great Depression hit Beverly particularly hard. In 1936, the town defaulted on its debt. [6]
    • A provincial administrator to manage the town from 1937 to 1948.
  • 07) Take Trail to the River
  • 08) Look downstream to the beautiful Rundle Park [7].
    • Named for an early Methodist missionary.
    • This was the site of the Beverly Dump.
    • As the community grew post amalgamation, there were calls to close the dump to reduce the smell, salvage men and the bears that inhabited the site.
    • Futuristic plans were drawn up… a more modest park was built-in its place in the mid-1970’s.
    • Rundle Park: With an area of 117.68 ha, the park was named for Rev. Robert Rundle. He was the first Protestant missionary to serve at Fort Edmonton and in fact the first permanent missionary of any church to settle west of Manitoba. In 1840 he came to Rupert’s Land at the request of the Hudson Bay. [12]
  • 09) The bridge to cross to the South Side of the river is named for Ainsworth Dyer, one of 4 Canadians killed in a friendly fire incident in Afghanistan [8].
  • 10) As you cross the bridge look for Gold Bar stream coming into the river.  Early miners panned for gold in the gravel bars here. [9. p.13]
  • 11) The Gold Bar Waste Water plant [10, p.6]
    • Open in 1956.
    • Waste water is sent to the refineries where it reduces their water needs.
  • 12) Take a moment to look north along 50th Street – yup no bridge yet. [6]
    • Promised a new bridge for vehicular traffic across the North Saskatchewan River at 50 Street, residents of Beverly cast ballots in a referendum regarding amalgamation with Edmonton in which 62% voted in favour. The 50th Street bridge has yet to materialize.
  • 13) Highlands Golf Course [1, pp.254-255] and [11]
    • Built in 1929  surrounding the Premier Coal Mine.
    • The original lease started in 1929 for a 21-year term with a 20-year option to renew (1970).
    • The current lease is for 50 years starting in 1989 with a 10 year extension.
    • occasional sink holes from the coal mine cause some trouble for the course.
    • The Capilano Freeway (now Wayne Gretzky Drive) impacted the golf course when it was constructed in 1969.

The Sources

  1. Historic Walks Of Edmonton, by Kathryn Ivany.
  2. Wikipedia: https://en.wikipedia.org/wiki/Highlands,_Edmonton.
  3. City Museum of Edmonton https://citymuseumedmonton.ca/2015/05/19/when-trolleys-came-to-edmonton/
  4. Street Car lines circa 1944; http://www.tundria.com/trams/CAN/Edmonton-1944.shtml.
  5. Beverly Heights: https://en.wikipedia.org/wiki/Beverly_Heights,_Edmonton.
  6. Beverly, Alberta: https://en.wikipedia.org/wiki/Beverly,_Alberta.
  7. Edmonton: A World Class Dump, Part Three – Salvage Men, Coal Mines, and a Futuristic Weir; https://citymuseumedmonton.ca/2016/12/06/world-class-dump-3.
  8. https://en.wikipedia.org/wiki/Tarnak_Farm_incident
  9. Nature Walks and Sunday Drives ‘Round Edmonton Paperback – Nov 14 2003 by Harry Stelfox (Author),‎ Gary Ross (Illustrator)
  10. Comprehensive valuation report; City of Edmonton – Gold Bar Wastewater Treatment Plant: http://webdocs.edmonton.ca/occtopusdocs/Public/Complete/Reports/CC/CSAM/2009-01-20/2009PW2573%20-%20Attachment%202rev.pdf
  11. Highlands Golf Course: http://www.highlandsgolfclub.com/About-Us.
  12. Wakahegan Trail Guide, 7th Edition.

Other Resources

  1. 1). Edmonton and District Historical Society, http://www.historicedmonton.ca.
  2. Highlands Historical Society Society, facebook.com/highlandshistoricalsociety

Pin the Tale on the Disruption

Posted on by
1

This is a conclusion of a previous blog series entitled ‘Seven Days of Disruption‘.  These blogs discussed a variety of potential disruptions that could affect the public service.  During a Financial Management Institute conference entitled ‘Disruptive Writers‘ on November 22, 2017, 110 presenters, attendees and volunteers were asked to rank one of 18 disruptions as having the greatest impact on the Canadian Public Service over the next 10 years.  This blog will describe the game ‘Pin the Tale on the Disruption‘ (in case I want to use it in the future) and describe the results of the game including the response rate.

The Results of the Game

The number one identified disruptor (+15%) was the emergence of Artificial Intelligence.  Four disruptors were given more than half of the scoring, these four were:

  1. Evolving Artificial Intelligence
  2. Growing debt Overhang
  3. Cyber Insecurity
  4. IT Revolution 2.0 and the Rise of the Machines

Despite the inclusion of sociopolitical disruptors (e.g. Canadian regionalism, Canada in the age of Trump or De-Population Waves), technology disruptors represented more than a third of the scoring and were in first, third and fourth place respectively.  While hardly a scientific or statistically sound survey, the game ‘Pin the Tale on the Disruption’ should help public service leaders plan and align operational and tactical plans over the next decade.

Results of ‘Pin the Tale on the Disruption’ – FMI Event 2017-11-22

How the Game was Played

  • As part of the pre-conference notes and as a physical hand out, each participant were given 12 dots and a listing of disruptions to vote on.
  • Participants could also ‘make your own disruption’ if they thought one or more were missing (note, no additional disruptions were noted).
  • Dots were applied before the conference and during the break.
  • Instructions were provided upon registration, informally at each table by event leader and then en masse at the start of the session.
  • By apply dots, attendees received a ticket which entered their name in a draw for a prize (note, the tickets were inadvertently forgotten so prizes were given out via other means).

Future Notes on How the Game Went

  • Approximately 1,200 dots were distributed and 757 dots were applied for a response rate of 63%.
  • This response rate is lower than expected (with an ideal around 80%) and could be improved via better floor walkers and in-event promotion.
  • The moderator and the game coordinator had a good rapport.
  • Identifying and having a roving microphone in advance to encourage audience participation would have been ideal.
  • A pre-game run through with the moderator and participants would have been beneficial.

Blog Annex – FMI Event Description:

Disruptive Writers. 

This FMI event will focus on real and potential disruptions and how to navigate change.  Three local authors have each written about this topic from very different perspectives.  These authors will describe their books and their journey to becoming authors.