Accounting is a business that I don’t know much about, so I’m going to this one-day conference in St. Louis in July (plus I can visit my brother).
The Accounting Technology Conference topics are buried in the middle of the 2020 Group’s Seminars page. So here they are, all by themselves, verbatim.
Accountants Technology Conference (Course Code: ATC) 9:00 AM-5:00 PM
This information packed 1-day seminar will showcase the latest and best technology that cutting edge firms are using to drive productivity, encourage efficiency, market effectively and attract (and retain) the best talent. This program will help you think strategically about your IT. (CPE credits: 8)
- Moving to less paper
- Why the Cloud?
- Work flow and doc management
- Top technology initiatives
- Setting an IT budget
- Web-based accounting
- Portals and security
- Apps, gadgets and other tools
If you’re an accountant and would like me to be on the lookout for something, let me know. If you would like to go too, you can register here. (They ask you what conference and venue you want on a later page).
My laptop is my business’ life. So I do the usual techie stuff—firewall, antivirus, spyware scans, backups, and encryption.
But I also have insurance. My insurance agency just used the zappos.com data breach to remind me that general business insurance doesn’t cover this sort of thing. The fact that you’re reading my web site means you should know this. Here’s my insurance company’s piece on cyber liability coverage.
Fortunately, one of my first clients required me to have Professional Liability and E&O coverage with cyber liability provisions. I’m glad they did. I never had the chance to cheap out, and they told me what kind of coverage I needed.
The right insurance is like a parachute. If you need it, and don’t have it, you probably won’t need it ever again.
Those who wonder how to mesh Agile with a portfolio management or gating process will find some help in Agile Idea Qualification and Project Initiation, an engaging, 50-minute webinar by Sally Elatta.
Sally highlights the similarities between Agile and Lean. I wholeheartedly agree with her that the jelled, multi-functional team (BA, DBA, UI/UX, programmer, QA), not the individual “resource,” is the real unit of value creation in the software-intensive business. Rather than assembling teams around projects, flow work to teams.
In the early days, Agile started with, “in the beginning, there was the Project.” Sally backs up a couple of steps, to the Idea Qualification stage, which proceeds even Project Initiation. Tom Koulopolous teaches a lot of the same concepts. There are many more ideas than there is capacity to implement them, and that’s a good thing. Ideas are the gist of the innovation mill. There must be a central clearing house for idea evaluation, and it must be transparent and respectable. Though the norm, WSTL is just another form of the curse of local optimization.
Idea Qualification can, and must, be quick, both low effort and short cycle time. Sally recommends qualifying ideas by asking:
- What is its basic value proposition (make money, save money, improve customer satisfaction, improve competitiveness, stay in compliance, or KTLO—Keep The Lights On)? How can its success in delivering that value be evaluated? Qualitatively is better.
- Is it aligned with strategic direction? [Or, Iwould add, “Is it such a breakthrough idea that it represents a change in strategic direction?” This should be uncommon.]
- Does it have an empowered, engaged, knowledgable sponsor who is willing to see it through to Done and then take responsibility for the value created, 3-6 months after Done?
- Is it Feasible? (Do we have the time, money, know-how, and access to the necessary information and technology)?
Sally wisely recommends the use of a Kanban wall (visual representation of tasks and queues, with a limit on WIP—Work In Process—for every step) to manage Idea Qualification. Her explanation of a Kanban wall starting at about 28:45 in the webinar is very helpful. In addition to being Qualified, Ideas that are forwarded on to the next step, Project Initiation, must be prioritized. The Lean/Agile principle of minimal cycle time/WIP processes executed by standing teams off of a prioritized backlog, is used everywhere.
During Initiation, a portion of the implementation team, and the prospective sponsor, revisit the vision, measurable value, and feasibility (cost, skills, and technology) from Qualification, and add high-level requirements and costs, alternative solutions, a roadmap, and a bit more detail about how and when we will measure value. Projects that are approved to move on must also be prioritized. As Sally cleverly illustrates with the “Name Game,” starting at about 8:30 in the webinar, starting more projects than you have capacity just leads to multitasking which slows everything down.
Sally’s webinar provides a lot of help for business-side sponsors of software projects, which delights me because I think this is the hardest role and also the one with the greatest ability to affect significant change for the better. Starting at about 46:15 in the webinar, she provides a six-step process for evaluating value.
- Confirm (it should already have been identified) the value driver (revenue, cost, etc.)
- Identify the measure
- Gather as-is data (using the Lean principle of Go See)
- Define target measures—To Be—a valuable insight is to make this multiple thresholds, with a stretch goal and a target as well as a failure threshold; she also introduces probabilities or percentages, which is something I harp on when it comes to cost estimation
- Plan for and commit to measurement of actual outcomes
The higher the overall trust level in your organization, the better this will work. But even in a low-trust organization, there will be benefits, if you have the courage. One of the first gifts of Agile is transparency. Following this process of idea intake, qualification, initiation, and closing the loop with post-project measures, will reveal sources and sinks of trust.
I was a bad basketball player—pathetically bad. I was too bad even for scrub-team intramural basketball.
But I played a lot of “Horse” on the hoop on the garage.
(If you know Horse, skip this paragraph). In Horse, the first player calls a shot. If doesn’t make it, the next player calls a shot, and so on, until someone calls a shot and makes it. Then, everybody else in turn has to make the same shot. If they don’t, they get a letter, starting with H. When you’ve spelled HORSE, you’re out. The game continues until there’s only one player left.
The trick to Horse is calling shots that you can make and others can’t. Sometimes the shot-calling gets elaborate. Read more of this article »
Robert’s speaking on “The Software-Intensive Business—What every non-techie needs to know about computer and web programming for profit (and fun)” at the Madison Area Business Consultants monthly meeting on Thursday, October 14th, MG&E Innovation Center, 7:30 AM (in the morning).
I’ve long told my customers that big waterfall software specs are more like insurance policies than blueprints, especially when I hear the phrase “sign-off” more than once a week. They are part of Covey the Younger’s Trust Tax.
But in Deniability, Seth Godin puts it better that I ever could. “At some point, that effort [anticipatory CYA] becomes so great you never actually ship anything, which of course is the very best protection against failure.”
Q: Why were they late for the meeting?
A: They didn’t leave soon enough.
But…they got stopped by a train, and they remembered that they needed to pick up a loaf of bread, and…they have a slow car!
Details like speed limits and the police aside, what do the car, and the bread, and the train have to do with it? The trip took 25 minutes, five of it spent waiting for the train, and five of it in the convenience store, and fifteen of it driving. They left 20 minutes before the meeting, and they were five minutes late.
Well, they didn’t plan for the train or the bread.
Do they ever plan for the train or the bread? Read more of this article »
If your firm hires or contracts programmers, and your business results depend on their work (and if your business results don’t, why did you hire or contract programmers?), this question is for you. Read more of this article »
Think that your software team performs best under pressure?
Not if what a Harvard Business School professor learned about other knowledge workers—auditors and consultants—applies to programmers, too.
In Feeling the Heat: The Effects of Performance Pressure on Teams’ Knowledge Use and Performance, Heidi Gardner explains that the pressure triggers “threat rigidity,” and causes “reduced cognitive processing.” Teams under pressure are also more likely to defer to “high-status” team members, rather than make full use of those with the most relevant, specific expertise.
Prof. Gardner’s research involved 72 teams of management consultants and auditors across twenty regional offices of a Big Four firm.
Leading a software-intensive business means overseeing some high-stakes projects–there’s no way around it. But don’t assume that the people doing the work will respond to the pressure the way you do.