Last night we went live with a refresh of the Church newsroom web site. The old one is here, and the new one is here.
This is an example of a complete re-write of a web site with new technology, new content and a new supporting content management process. This solution took only a few months and, going forward, requires no development to update content.
The audience of the web site is "news media, opinion leaders and the public."
We're still working on a few bugs so be patient with us.
Book Club: Leadership and Self-Deception
I've just started reading Leadership and Self-Deception, Arbringer Institute. Has anyone read it? If so, I invite your comments. If not, grab a copy and join me in reading it!
1: World Class I.T.
I contribute in making ICS a world-class IT organization that sets the standard for the industry.
How good does the Church I.T. department really need to be, anyway?
We have to be the best--the absolute best. The Lord and the Church deserve the best computer systems and solutions possible. And our group is focused on adapting our people, processes & systems to enable that to happen. My predecssor (Eric Denna) made a big deal out of stating that we wanted to be a "World Class I.T. Organization." So why state that? How obvious can a goal be?
It's suprising how many people both in our department and among our customers don't have that expectation of us. "You're improving," say many. "You don't need to be the best. You just need to be 'good enough,'" say others.
That didn't sit well with Eric, and it doesn't sit well with me. I visit other countries occasionally in the course of my job. I always try to meet local members of the Church. These are wonderful people. They're faithful, smart, spiritual people. And they pay tithing, just like people in the U.S. do. I consider it a sacred duty to spend that money carefully.
Which is why we have to be world class. We need to spend every I.T. dollar as efficiently and effectively possible. We need to be wise in using a thorough "business case" analysis for each solution we consider. We need to be efficient in creating, implementing, running and retiring systems. We need to pay enough to engage the kinds of people we need, but not so much as to be wasteful or to attract people who are just coming here for the money. We need to have rock-hard security and mature ITIL operational processes. We need to create solutions which solve real customer needs.
We can't get by with "good enough." "Good enough" is wasteful. "Good enough" isn't good enough.
We need to be and we CAN be World Class.
How good does the Church I.T. department really need to be, anyway?
We have to be the best--the absolute best. The Lord and the Church deserve the best computer systems and solutions possible. And our group is focused on adapting our people, processes & systems to enable that to happen. My predecssor (Eric Denna) made a big deal out of stating that we wanted to be a "World Class I.T. Organization." So why state that? How obvious can a goal be?
It's suprising how many people both in our department and among our customers don't have that expectation of us. "You're improving," say many. "You don't need to be the best. You just need to be 'good enough,'" say others.
That didn't sit well with Eric, and it doesn't sit well with me. I visit other countries occasionally in the course of my job. I always try to meet local members of the Church. These are wonderful people. They're faithful, smart, spiritual people. And they pay tithing, just like people in the U.S. do. I consider it a sacred duty to spend that money carefully.
Which is why we have to be world class. We need to spend every I.T. dollar as efficiently and effectively possible. We need to be wise in using a thorough "business case" analysis for each solution we consider. We need to be efficient in creating, implementing, running and retiring systems. We need to pay enough to engage the kinds of people we need, but not so much as to be wasteful or to attract people who are just coming here for the money. We need to have rock-hard security and mature ITIL operational processes. We need to create solutions which solve real customer needs.
We can't get by with "good enough." "Good enough" is wasteful. "Good enough" isn't good enough.
We need to be and we CAN be World Class.
Organizations are like People
An organization is like a person. It can be healthy, sick or even dead. It can be born (or re-born). It needs to be fed and entertained. And it needs regular sleep. It's interesting to me that an organization has a personality. It can be social or private, funny or somber, passive or aggressive (or passive aggressive), steadfast or volatile , frivolous or staid.
Take software companies.
The following roughly describe some actual individuals I know:
If you look at each carefully, you'll also see the personality of at least one software company.
I initially went through significant culture shock in coming from Microsoft to the Church. It was like dancing with two completely different partners. Microsoft is an environment where confrontation and debate rule the day, where decisions are usually made based on the bottom line, and where a meritocracy allows young, sometimes impetuous leaders to rise quickly through the ranks, creating a wake as they rise. The Church is... Well... Not like that. Decisions are made based on revelation and a deep concern for the members of the Church. Confrontation and debate is replaced by consideration and respect. Leaders are typically much more mature and steady. Imagine how typical management challenges like recruiting, process design, performance management, and policy compliance would be different in those two environments.
With that in mind, we set out to define the personality, or culture, we wanted our organization to embody. This is way more challenging than it sounds. As a leadership team, we sat down and created a list of attributes we thought represented the organization we felt we could become and which would be most effective in the Church environment. We left off wholly obvious things like "we're honest" and "we believe the Church is true." Some of the things which made the list, however, might seem obvious but needed reinforcement.
These attributes we codified apply to the I.T. department of the Church only. Other groups within the Church have similar, but different sets. I should mention that the book Journey to the Emerald City provided a very valuable context and framework for thinking about these "cultural beliefs." Hyrum Smith's work on having a "personal constitution" was also influential.
Over the next few weeks, I'll list and explain these attributes as I get time. Feel free to comment and I'll post some of the interesting and relevant ones.
COMMENTS ON.
Take software companies.
The following roughly describe some actual individuals I know:
- Woman: steady, attentive to details, and averse to big risks.
- Boy: creative, brilliant and unfocused.
- Girl: thoughtful, honest and passive.
- Man: litigious, aggressive, and arrogant.
If you look at each carefully, you'll also see the personality of at least one software company.
I initially went through significant culture shock in coming from Microsoft to the Church. It was like dancing with two completely different partners. Microsoft is an environment where confrontation and debate rule the day, where decisions are usually made based on the bottom line, and where a meritocracy allows young, sometimes impetuous leaders to rise quickly through the ranks, creating a wake as they rise. The Church is... Well... Not like that. Decisions are made based on revelation and a deep concern for the members of the Church. Confrontation and debate is replaced by consideration and respect. Leaders are typically much more mature and steady. Imagine how typical management challenges like recruiting, process design, performance management, and policy compliance would be different in those two environments.
With that in mind, we set out to define the personality, or culture, we wanted our organization to embody. This is way more challenging than it sounds. As a leadership team, we sat down and created a list of attributes we thought represented the organization we felt we could become and which would be most effective in the Church environment. We left off wholly obvious things like "we're honest" and "we believe the Church is true." Some of the things which made the list, however, might seem obvious but needed reinforcement.
These attributes we codified apply to the I.T. department of the Church only. Other groups within the Church have similar, but different sets. I should mention that the book Journey to the Emerald City provided a very valuable context and framework for thinking about these "cultural beliefs." Hyrum Smith's work on having a "personal constitution" was also influential.
Over the next few weeks, I'll list and explain these attributes as I get time. Feel free to comment and I'll post some of the interesting and relevant ones.
COMMENTS ON.
Open Source
A number of you mentioned that you were interested in how/if the Church uses or contributes to the open source community.
The promise of open source, I guess, is free software which is more stable because the world is helping to find and fix your bugs. What's not to love? We'd love it to work out that way more often. We've had some success using open source stuff, but we've also had some problems. Following are a few random places we've dabbled.
1) Java Stack. We use several open source components for our java stack (including Hibernate, Spring and others). It has been painful for us to integrate these all into a common stack, and we've done most of that work ourselves. Now that it's done, our developers are extremely productive in it. You have to ask if the money we've spent developing and the money we will spend keeping it up-to-date is worth the "vendor independence" we gain from not buying some commercial offering. To date we think we're still on the right path, but we'll be watching carefully as tools mature.
2) Linux. Linux is free! Or we wish it were. We pay for libraries we need, we pay for integration services and we pay for support. We hope we won't end up paying for using the IP in Linux, but one never knows. "Free" just doesn't mean what it used to mean.
3) Nagios. We use Nagios for monitoring in our data center. This has been a pretty good experience for us so far. Some of our developers have contributed back to this project (see next point).
4) Contribution. I'm conflicted on having developers contribute to open source projects. On one hand, it's the polite thing to do. You take from the community--you should give back. In addition developers think it's cool to contribute to open source projects. It's a badge of honor, in a way. On the other hand, there are some downsides. First, you risk legal & intellectual property issues if people aren't careful. Second, it can be a massive productivity drain. If you have developers on staff (or if you're a developer interested in getting involved) be cautious. You'd be shocked out how much time can whir by as a developer gets involved in both downloading and contributing to open source projects. It's one thing to download and use the binaries. It's another thing altogether to download the source, modify it, build it, test it and then check your changes back into the sky.
5) Feature Sets. I've found the feature sets wanting in some of the open source software I've played with. OpenOffice is getting much better, but still misses some of those key little features I'm used to in MS Office. I'm hoping it catches up. I've yet to find an email/calendaring systems that comes close to Exchange & Outlook. Open source ERP? Don't we wish? It seems like almost all of the Open Source we might care about is "getting close" or "almost there."
To be clear, I love the idea of Open Source. However it's not the panacea that many would claim. There are hidden costs and feature/service tradeoffs to be made. We carefully weigh each option (both the proprietary and the open source alternatives) and try to make decisions on the merits.
There is an interesting place we'd like to use the open source concepts, however. If you're like me, you've developed a number of spreadsheets, databases and simple apps to help with various callings you've had. We'd like to make that easier for developers to do and to share what they've done. Stay tuned. I'll be talking more on the blog about how we're going about making that happen...
The promise of open source, I guess, is free software which is more stable because the world is helping to find and fix your bugs. What's not to love? We'd love it to work out that way more often. We've had some success using open source stuff, but we've also had some problems. Following are a few random places we've dabbled.
1) Java Stack. We use several open source components for our java stack (including Hibernate, Spring and others). It has been painful for us to integrate these all into a common stack, and we've done most of that work ourselves. Now that it's done, our developers are extremely productive in it. You have to ask if the money we've spent developing and the money we will spend keeping it up-to-date is worth the "vendor independence" we gain from not buying some commercial offering. To date we think we're still on the right path, but we'll be watching carefully as tools mature.
2) Linux. Linux is free! Or we wish it were. We pay for libraries we need, we pay for integration services and we pay for support. We hope we won't end up paying for using the IP in Linux, but one never knows. "Free" just doesn't mean what it used to mean.
3) Nagios. We use Nagios for monitoring in our data center. This has been a pretty good experience for us so far. Some of our developers have contributed back to this project (see next point).
4) Contribution. I'm conflicted on having developers contribute to open source projects. On one hand, it's the polite thing to do. You take from the community--you should give back. In addition developers think it's cool to contribute to open source projects. It's a badge of honor, in a way. On the other hand, there are some downsides. First, you risk legal & intellectual property issues if people aren't careful. Second, it can be a massive productivity drain. If you have developers on staff (or if you're a developer interested in getting involved) be cautious. You'd be shocked out how much time can whir by as a developer gets involved in both downloading and contributing to open source projects. It's one thing to download and use the binaries. It's another thing altogether to download the source, modify it, build it, test it and then check your changes back into the sky.
5) Feature Sets. I've found the feature sets wanting in some of the open source software I've played with. OpenOffice is getting much better, but still misses some of those key little features I'm used to in MS Office. I'm hoping it catches up. I've yet to find an email/calendaring systems that comes close to Exchange & Outlook. Open source ERP? Don't we wish? It seems like almost all of the Open Source we might care about is "getting close" or "almost there."
To be clear, I love the idea of Open Source. However it's not the panacea that many would claim. There are hidden costs and feature/service tradeoffs to be made. We carefully weigh each option (both the proprietary and the open source alternatives) and try to make decisions on the merits.
There is an interesting place we'd like to use the open source concepts, however. If you're like me, you've developed a number of spreadsheets, databases and simple apps to help with various callings you've had. We'd like to make that easier for developers to do and to share what they've done. Stay tuned. I'll be talking more on the blog about how we're going about making that happen...
LDS Church Tech Talks
We're planning to do tech talks in SLC, Provo and in Seattle where we'll talk about some of the technologies the Church uses.
The audience is intended to be software and system engineers who have an interest in what we're doing at the Church.
What topics would you be interested in?
Comments are ON.
The audience is intended to be software and system engineers who have an interest in what we're doing at the Church.
What topics would you be interested in?
Comments are ON.
Developing Church Software
As I mentioned in my first post, the Church is a diverse operation and therefore has a diverse toolbox of software required to operate:
* The MLS software used by ward clerks
* ERP (we currently use Peoplesoft)
* Other financial (tax, GL, payments, investments, etc.)
* Supply Chain (manufacturing, inventory, retail)
* Public-facing web sites (lds.org, mormon.org, missionary application, etc.)
* Facilities management software
* Etc.
Given the diverse nature of our work, we don't take a "one size fits all" approach to our software methodology. However, for the most part we subscribe to some of the principles of Agile Software Development.
The misconception about Agile is that it is itself a software methodology. It is not. Agile is a set of principles--or preferences. The basic principles are these:
Many sling about the term "Agile" as an excuse to be reckless, ill-prepared, or undisciplined in their development.
"We don't talk about dates... we're agile."
"The customer is right! If they want to grow scope they can do it... we're agile!"
These are of course missing the point. "Agile" isn't a methodology. It isn't a panacea. It isn't a cure for disease. And it's not an excuse. A software methodology which is "Agile" will allow the developers to uncover and solve problems in real time and will allow the flexibility to swap scope as necessary. Delivery dates however can still be immutable, or at least inflexible, in an Agile software methodology. Scope can still be explored and agreed upon up front in an Agile software methodology.
I'll give you an example. We just started working on a major revision of one of the Church web sites. We plan to go live in Q1 of next year. We could have spent days or weeks or even months writing detailed specifications, getting contracts in place, negotiating, etc. But instead we worked with the Church department to create a prototype of what they wanted.
We employ a team of Interaction Designers who are just phenomenal. They can sling xhtml and css with the best of them, but they are also terrific with Photoshop. They will meet with a customer and talk through the workflow. They'll come back a few days later with a working prototype which allows the customer to give feedback based on what they see and play with, not what they read about in a 400 page document. Our interaction designers will even dummy up data for reports giving the customer a feeling for what the real deal will look like. When the prototype is all done, the customer can see precisely what we will deliver to them.
The proto for this web site is now done. We're currently working on a schedule, and we will accurately be able to predict when we'll be finished and how much it will cost.
Granted, things change once users start using the system. But that kind of change we can deal with. The changes that have been painful for us in the past are when we get nearly done with a project only to find out we didn't actually understand the customer requiements in the first place. Using protoypes as specs helps solve that problem.
I read about this approach in a book called The Inmates are Running the Asylum a number of years ago, but wasn't able to successfully implement the ideas when I managed teams at Microsoft. We never seemed to have enough Interaction Designers, or we were always in a hurry to keep developers busy so we'd skimp on up-front Interaction Design, relegating our designers to Photoshop technicians.
But we're making it work at the Church and the approach is reaping dividends for our customers.
* The MLS software used by ward clerks
* ERP (we currently use Peoplesoft)
* Other financial (tax, GL, payments, investments, etc.)
* Supply Chain (manufacturing, inventory, retail)
* Public-facing web sites (lds.org, mormon.org, missionary application, etc.)
* Facilities management software
* Etc.
Given the diverse nature of our work, we don't take a "one size fits all" approach to our software methodology. However, for the most part we subscribe to some of the principles of Agile Software Development.
The misconception about Agile is that it is itself a software methodology. It is not. Agile is a set of principles--or preferences. The basic principles are these:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Many sling about the term "Agile" as an excuse to be reckless, ill-prepared, or undisciplined in their development.
"We don't talk about dates... we're agile."
"The customer is right! If they want to grow scope they can do it... we're agile!"
These are of course missing the point. "Agile" isn't a methodology. It isn't a panacea. It isn't a cure for disease. And it's not an excuse. A software methodology which is "Agile" will allow the developers to uncover and solve problems in real time and will allow the flexibility to swap scope as necessary. Delivery dates however can still be immutable, or at least inflexible, in an Agile software methodology. Scope can still be explored and agreed upon up front in an Agile software methodology.
I'll give you an example. We just started working on a major revision of one of the Church web sites. We plan to go live in Q1 of next year. We could have spent days or weeks or even months writing detailed specifications, getting contracts in place, negotiating, etc. But instead we worked with the Church department to create a prototype of what they wanted.
We employ a team of Interaction Designers who are just phenomenal. They can sling xhtml and css with the best of them, but they are also terrific with Photoshop. They will meet with a customer and talk through the workflow. They'll come back a few days later with a working prototype which allows the customer to give feedback based on what they see and play with, not what they read about in a 400 page document. Our interaction designers will even dummy up data for reports giving the customer a feeling for what the real deal will look like. When the prototype is all done, the customer can see precisely what we will deliver to them.
The proto for this web site is now done. We're currently working on a schedule, and we will accurately be able to predict when we'll be finished and how much it will cost.
Granted, things change once users start using the system. But that kind of change we can deal with. The changes that have been painful for us in the past are when we get nearly done with a project only to find out we didn't actually understand the customer requiements in the first place. Using protoypes as specs helps solve that problem.
I read about this approach in a book called The Inmates are Running the Asylum a number of years ago, but wasn't able to successfully implement the ideas when I managed teams at Microsoft. We never seemed to have enough Interaction Designers, or we were always in a hurry to keep developers busy so we'd skimp on up-front Interaction Design, relegating our designers to Photoshop technicians.
But we're making it work at the Church and the approach is reaping dividends for our customers.
Subscribe to:
Posts (Atom)