Feature Request: Visiting Teaching Companionship Report

Discussions around using and interfacing with the Church MLS program.
User avatar
daddy-o-p40
Member
Posts: 237
Joined: Wed Feb 21, 2007 1:22 pm
Location: USA
Contact:

#11

Post by daddy-o-p40 »

Tom, nice clarification.

In the IT culture I come from developer(s) or sometimes designer(s) refers to the team over the product. Programmers or Coders refer to the people actually writing code. Think I'll add "Attn: Membership Dept" to feature requests from now on.

We are very grateful that DJC is available here. This request was first made in 2005 by our stake and many times since. Keeping our fingers crossed.
"What have I done for someone today?" Thomas Monson
rpyne
Member
Posts: 228
Joined: Fri Jan 19, 2007 1:13 pm
Location: Provo, Utah, USA

#12

Post by rpyne »

tomw wrote:The reason is that we are trained at the Church that the developers take their orders from the "customer" who is typically the department or organization that they are working for.
Therein lies problem number one, in the real world the END USERS (the thousands of clerks) are the "customer".
tomw wrote:if we were to let the developers do work without the "customer" being involved in the priority and resource scheduling, we would have a problem.
That is what product and project managers are for.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#13

Post by WelchTC »

rpyne wrote:Therein lies problem number one, in the real world the END USERS (the thousands of clerks) are the "customer".
Think of it this way. ICS's customer (membership department for example) should have as their customer the clerks. So the chain should look like this:

Clerks -> Membership Deparment -> ICS (Programmers)

If membership department were left out of the discussions between clerks and programmers there would be a lot of problems.
rpyne wrote:That is what product and project managers are for.
Yes, exactly. The product managers (who live in the customer's world) should be interfacing with the customers to find out what is needed. That is how we have it setup at the Church.

Tom
rpyne
Member
Posts: 228
Joined: Fri Jan 19, 2007 1:13 pm
Location: Provo, Utah, USA

#14

Post by rpyne »

tomw wrote:Think of it this way. ICS's customer (membership department for example) should have as their customer the clerks. So the chain should look like this:

Clerks -> Membership Deparment -> ICS (Programmers)

If membership department were left out of the discussions between clerks and programmers there would be a lot of problems.
As it stands, it appears that the clerks have been left out of the loop. The general feeling is that we (clerks) may as well throw our feature requests and bug reports in the garbage can directly and save a step in the process. I know of feature requests that have been suggested repeatedly by numerous clerks for five years that for all we know have been completely ignored.

The most significant feature request that comes to mind because it is making reports created by MLS less useful every day is the need for phone numbers and email addresses for each individual, not just for the household.
User avatar
johnshaw
Senior Member
Posts: 2273
Joined: Fri Jan 19, 2007 1:55 pm
Location: Syracuse, UT

It Service Management

#15

Post by johnshaw »

Tom,

As someone who does very similar work for an organization, I completely agree with the formula that you have put together. Maybe I could clarify something a bit.

The Customer of the Membership Department is the community of clerks
The Customer of the ICS Programmers is the Membership Department.

Everyone has a customer, and the clerks have not been left out of the loop.

I have no way of knowing, personally, how the church does bug fix requests, but if it follows typical software development, there are multiple factors for how fixes are prioritized. For Example, I don't know how many clerks have been requesting the ability to download their reconciliation forms directly to the computer and no longer receive them in the mail. I doubt it would be that many, it's just not that big of a problem, a suggested improvement, maybe. But, the Church has obviously used another criteria for putting development resources to writing that code. As I think about it, there is probably a large amount of money that the church is now saving in distributing and mailing those statements.

The previous post labeled a particular request as 'most significant feature request that comes to mind', most significant in what way? Does it save more of the Lord's money than the second or third most significant features? Will it support a new quarterly report for tracking new members? The list goes on...

We as a community of clerks, need to remember that in the future. Maybe someone could help us understand how these requests are collected, quantified, and assessed?
jdlessley
Community Moderators
Posts: 9861
Joined: Mon Mar 17, 2008 12:30 am
Location: USA, TX

#16

Post by jdlessley »

rpyne wrote:As it stands, it appears that the clerks have been left out of the loop. The general feeling is that we (clerks) may as well throw our feature requests and bug reports in the garbage can directly and save a step in the process. I know of feature requests that have been suggested repeatedly by numerous clerks for five years that for all we know have been completely ignored.

The most significant feature request that comes to mind because it is making reports created by MLS less useful every day is the need for phone numbers and email addresses for each individual, not just for the household.
Please do not come to the conclusion that since some recommendations, more specifically yours and other clerks, have not been included in any fixes to date that the users, clerks, have been left out of the loop. Remember, there are processes and issues at work beyond what is readily visible by way of the end product. The LDS Technology Forums were created to as an avenue for dialog on technology issues. The developers and the technology teams at Church headquarters do read the posts to these forums and take them into consideration. Since MLS is a world-wide user product there are a lot of issues, and some more important than others, involved in development efforts.
rmrichesjr
Community Moderators
Posts: 3829
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon, USA

#17

Post by rmrichesjr »

jshawut wrote:Tom,
...
The previous post labeled a particular request as 'most significant feature request that comes to mind', most significant in what way? Does it save more of the Lord's money than the second or third most significant features? Will it support a new quarterly report for tracking new members? The list goes on...
...
The lack of individual phone numbers in MLS and LUWS prevents timely and reliable contact between leaders and members. That ought to rate it pretty high on the priority list. For example, as counselor to an elders quorum president, I need to be able to contact home teachers for reporting of home teaching, etc. I had lost the hand-written note with the phone number of one particular home teacher. The "household" number is for his wife's phone. Despite her best efforts, it takes much longer to contact him than if MLS had his number. I hope the development organization is able to get this enhancement implemented before very many more years go by.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#18

Post by WelchTC »

The clerks are not left out of the loop. These forums are 1 of the avenues that are used to gather input. But there are many very complex issues that need to be considered for many new features. Keep the suggestions coming and have faith that some of these suggestions will make their way into the product in the future.

Tom
Locked

Return to “MLS Support, Help, and Feedback”