If there isnt a documented process, policies or set of standards that your organization uses to define it's best practices on how business is conducted, then by default your software may create it for you. Software and the solutions you use will have built in policies and processes. So in lieu of you picking the best way to run your business you allow the software to do it for you. WOW! How come I had never really put that thought together in my head?
Ok, so in many cases following the rules and policies dictated by your software is a good thing. Many times these are based on regulations, business practices and audit standards. But beyond that should you determine the most effective way to run your organization, then try to adapt those practices to your software. Rather than seeing how the software works, then letting that dictate your process?
Slow down Steve, where is all of this craziness coming from?
I was excited to be given the chance to present my #10ntc Ignite session for a small group over at the Great Book Foundation. My ignite session tries to relay a point about how technology staff talking about tools and solutions can kill your audience. After that I spend about 20 minutes talking all about IT Alignment stuff from the NTEN book. Then we opened it up for some questions and answers.
There was a group of questions that revolved around determining policy, planning technology strategy and staff roles in all of this. That is when someone asked about how do you manage a multi-layer technology strategy that meets the needs of the individual staff, each department and the full organization. If you are meeting all of those needs wouldnt that require multiple technology strategies and require those strategies to start from very different perspectives?
That lead me to try to explain how you do need to have a few parts to your IT Alignment strategy. This goes back to John Merritt's idea of the ART of the Technology. ART = Alignment, Relationship, Transparency. First, have a strategy to make the technology work so well that it is transparent, second work to build relationships between IT and the rest of the org, third move technology to meeting the mission through Alignment. So yes, it is a bunch of strategies, not just one focused on mission, but that is still the end goal.
Steve, you are so off track yet again, wasnt this post about software creating policy? Yes, it is about that and I am trying to get back to that if you would just let me.
This then loops us back to the comment about software creating policies and practices where there are none. If you dont have a well rounded technology strategy that is focusing on all three elements Alignment, Relationship and Transparency tied to the mission it is easy to let the tools take over.
WOW! Did you see how I just tied that all together and referenced the ignite session as well? ZOINKS!
2 comments:
Right on Steve, this is an example of "organic" process development.
Processes don't grow out of the ground, something shapes them and forces them.
If you aren't then something else is.
Steve wasted no time getting this off his chest and it's a good thing, too. We at the Great Books Foundation were so fortunate to have Steve talk to us and are proud that the discussion led to an idea. In fact, that's what the Great Books Foundation is all about--discussing ideas.
Having your software set your policies is often better than the status quo. Especially if the status quo is not having a policy at all. We were considering a new password policy when Moodle changed their policy to a pretty stringent one. That prompted us to set one that was more stringent than what we had, but not quite as stringent as the Moodle default. One wouldn't want your software to set policy in all cases, but it can be a point of discussion. We don't want the types of software lock-downs we see in schools in which we can't sent email to paying customers.
Post a Comment