Page 1 of 1
Posted: Wed Jan 31, 2007 10:58 am
As an employee of the Church, we are seeking experiences from the tech community on change management. As all technologist have had to deal with change management, we would like to receive your feedback on how your governance organization is structured? What is their relationship with development, operations, etc... What authority is given to governance over Change Management?
Posted: Tue Feb 20, 2007 3:22 pm
Wherever I have worked Change Management is just a part of life, its purposes are many, from keeping the live environment live and stable, controlling they technology and not letting it control you, audit trails on all systems so you know what happened when and why it happened.
So take an idea, it could be a patch, or improvement to the service, or a new software package.
It needs to go through several hoops before it is put into BAU
* Proof Of Concept
* Document, Document, Document
* Document, Document, Document
* Document, Document, Document
* Testing, interoperability, regression, User Acceptance, Stress
* Document, Document, Document
* Change acceptance of key stakeholders
* Promotion to live
* Document, Document, Document
Obviously change management is a big subject and many books have been written on the subject. I might suggest you get on some ITIL and Prince2 courses
Posted: Sun Mar 04, 2007 12:43 am
The biggest issue I see reference to technology issues in the church over the years is that we get an idea, and we implement it before really thinking through how that idea impacts everybody else in other organizations, positions, or responsibilities. Each time we get an idea, we need to conduct an extensive study to determine what other ideas can come about that might work in conjunction with it.
For example, lets take a look at the situation we now have about MLS and the LUWS having different e-mail addresses fields, one on a per-household basis, the other on a per-individual basis. From what I imagine, we had two completely issues taking place simultaneously that got us to where we are.
First we had a whole bunch of clerks and unit leaders complaining that MIS didn't have anywhere to put e-mail addresses, so everybody requested a field for that, a feature that got implemented in MLS.
Meanwhile we had a whole bunch of wards posting their own websites, which caused a number of problems as far as lacking unity in design, potential liabliity of how the church is represented, and so on. These concerns and suggestions eventually sparked this Local Unit Website Project, which seems to likely have been developed very much seperately from the MLS project even though they occurred much around the same era.
Before we didn't have any unit websites, and therefore there wasn't much we could do with e-mail addresses in conjunction to a website. The MLS guys got what they asked for -- a feature to record e-mail addresses. The unit website guys got what they asked for -- a place to post information on the web. Then the end users got to use both of these programs and realized that hey, there's a whole mess of new ideas that could come about if they were used in conjunction with each other... E-mail addresses of course, but then there's also updating one's address & phone, looking up one's own tithing history reports, submitting your home and visiting teaching stats, syncronizing the leadership directory, etc. etc. An extensive list of ideas came about as a result of the end users having the opportunity to discover and play around with the programs. Unfortunately this is far too late for brainstorming such ideas, as the development was already completed by the time it got into their hands.
Right now in MLS we have the e-mail addresses on records, but then we have this church policy that came out which says we can't print them in membership directories without the member's specific permission. So what if a member gives permissionf or leadership to use their e-mail address but not to publish it to the whole ward? Well, MLS doesn't have a little check mark to flag who's e-mail addresses can be published and who's can't. Why doesn't it have such a simple little check mark / flag? Because users didn't ask for it, and the reason we didn't ask for it was because we didn't have the policy to deal with in the past when there wasn't a place to put the e-mail addresses to begin with, and that was the focus of our suggestions.
Before anybody writes a single line of code, everybody in all departments (especially end users) need to know what the game plan is, including all of the future changes picked up along the way.
When someone suggests an idea, we can't just bounce the idea off all the other church departments to gain their approval, adding along whatever baggage they tack on without taking all of this baggage (policies, new ideas, feature suggestions, etc.) back to the very group of end users that suggested the original idea to gain their updated input. Perhaps their original idea needs modification based on everything everyone else added to it. Those changes need to be ironed out long before the project is handed to developers to start writing code.
I can see this what the purpose of these new forums is, and I am quite excited to learn of their creation.
Posted: Sun Mar 04, 2007 8:14 am
I agree we need better coordinating and communication between departments and users. This is a process we are trying to implement by using these forums, getting other departments involved with these forums, etc. It takes a VERY long time to do this because there are so many issues to work through and people to gather input from. However it is starting to happen and I am very excited about it.
One thing to keep in mind, however, is that just because everyone things it is a great idea do do something does not mean that we will. The Church is lead by revelation (even within Church management) and not by popular vote. However, in order to be guided by revelation, we need to do the proper homework. So ideas and suggestions and features all are considered.
Posted: Sun Mar 04, 2007 2:48 pm
jeffphil wrote:Before anybody writes a single line of code, everybody in all departments (especially end users) need to know what the game plan is, including all of the future changes picked up along the way.
No. This idea actually bothers me a lot. I'm working as a software engineer for the church, and I find that each department has different, conflicting guesses on how software should work and how it should be written. We often spend months, even years, trying to build a consensus before writing any software. Everyone is apparently afraid we'll build the wrong thing and have to start all over again.
While communication is good, our real problem is our habit of falling back to the waterfall development model. In the waterfall model, everyone spends a lot of effort to agree on a single best guess, then the software developers build that, and a few months later, the end users receive a completed system. The waterfall model is fatally flawed; see this ACM article: http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=110&page=2
Jeff, you seem to be advocating a waterfall model. Please don't. Instead, we need iterative development across the board with tighter feedback loops and lower communication overhead. You should not be afraid of change. In your email example, it really should not bother you that there are two email fields that are not compatible. You should instead see that as experience gained and an opportunity for a software iteration on both projects.
In general, we should work harder to improve existing software rather than guess what software might be right.
Posted: Sun Mar 04, 2007 7:25 pm
Shane, I think you're right. I work for The Generations Network (formerly MyFamily.com, Inc.) and we follow the model you would like to go to. It is more of a business model, get as much bang for your buck and do it fast. Obviously the Church doesn't want to do a 180 degree turn to become a business of sorts; however, I really think you are right in the iterative philosophy. You plan something out the best you can, but it must get out the door sooner than later. Consumers benefit more from this.
A year ago we began developing a build-on-demand book regarding historical facts and figures of a given surname. The customer placed the order, and immediately we had software workflows going through the process of running prewritten database queries, filling in PDF templates with the facts and charts, and sending the PDF to a third party printing company for fulfillment. The point of the story is we had a first version of the thing out in 6 months and made some revenue off the book (with the majority being good feedback). There was a developer that was very hesitant because he thought we didn't do it 100% right. If he were managing the project, it probably would have been cancelled or never finished. However, with our successful first launch, we then looked at the product and process and began redesigning both for a second iteration before the big holiday push. Both got better and we got even better response. Now we are looking at the process again and we now know better what works and what doesn't. We will be redesigning once more having had real experience.
My real point is that a reasonably well done product can be made in a timely manner, but sacrifices have to be made. You also cannot research the heck out of something and get all of the answers. You will miss the window of opportunity and there's just no way of accounting for everything. Architecture SHOULD always be changing, and for the better. That's just what works in the industry.
Well, I don't know if I've explained everything sufficiently. I am pretty new to the industry, but I do see something that is working well.
Posted: Sun Mar 04, 2007 10:25 pm
I just don't like to see us paint ourselves into the corner on occasion and then hear that it is too difficult to get ourselves out, when a little more planning ahead could avoid such problems.
Architecture SHOULD always be changing, and for the better.
I would say that the architecture we implement should and ought to allow for change. Most of what we hear is that the architecture we have poses many issues making improvements and changes difficult.
Posted: Mon Mar 05, 2007 7:31 pm
jeffphil wrote:I would say that the architecture we implement should and ought to allow for change. Most of what we hear is that the architecture we have poses many issues making improvements and changes difficult.
Yes, I agree with that. We're doing so much planning that we're not making room for flexibility. Although it is difficult for everyone to accept (particularly management), the iterative kind of model that mkmurrary has been using is much more efficient and successful.
Two Different Topics
Posted: Tue Mar 20, 2007 7:55 pm
There are two phrases in this industry with a history of evolution: Change Management and information Architecture.
This conversation suffers a bit from the evolution. Originally, Change Management was a technical (engineering) topic that referred to the coordinating of operational schedules for implementing change into production. In the days of mainframes, this was a critical discipline. Today, as it relates to the potential impact to an operating environment (risk management), this is still relevant.
Then, the consulting industry hijacked the term for the practices involved with the Business Process Reengineering movement. This was more focused on practices to mitigate the cultural impact of change.
This conversation has almost a hybrid feel to it. Both are relevant. Based on some of the thoughts being expressed, there is something else at play here. It is something that neither Forrester or Gartner are addressing. The highly disciplined history of Applications Development methods are colliding with the 'why not' design approach that evolved from the dotcom era (development at Internet speed).
Here is where life science models are relevant: add just enough structure to optimize results. Take a look at self-organizing principles. Optimize the results with feedback mechanisms (operational change management was often a 'formal', time-intensive feedback mechanism). The 'optimal' balance should always err on the side of output, unless lives (or a circut or two) are at stake.
This is the era for revolutionizing classic methodologies. Microsoft is taking the revolution all the way to the walls (links to webcasts in paragraph 4