As you may have guessed – my thinking tends to bias towards “systems thinking”. (And in Wendy’s utopian fantasyland – these systems result in projects. Because I like clean end points.)
In my last post, I mentioned that project plans (and the changes to them) can be used for capturing information as plans change and potentially identifying trends if things go off the rails.
We can use these plans for learning!
Project plans, to me, are a rough estimate of what the project team thinks should be done to get from point A to point B. It’s a living document, not carved in stone.
In my experience, the real value in the project plan is in getting the steps and “to do” list out of people’s heads and onto paper.
Once I have that “paper” (or, in many cases, a computerized project plan), I can:
So much of my life (and my business) is about goals and results.
Get the application launched by x date.
Desired result [add business objective here].... Read More
Recently, a system administrator acquaintance was asked to add a bar code to attendee badges for their big meeting.
They wanted to collect information on which sessions people attended during their conference.
You are working on a project.
You are tantalizingly close to finishing. To shipping. To going into production.
There’s just one more thing you need to do that takes just a little bit of time.... Read More
Imagine a high-stakes, politically sensitive IT implementation.
During the project, things go wrong. Really wrong. As in – having more than half of your risk register come true wrong.... Read More
In my previous job, I was an LMS Administrator (among other things).
I spent a LOT of time with that LMS.
Creating programs, configuring the LMS to support those programs, negotiating with my organization and the vendor for customizations, occasionally going into the code myself to make things work for my organization.
The more work I put into something, the more ownership I feel.... Read More