#mobmin Methodology | Mobile Ministry Magazine

Originally Published 4/12/2012; moved to this page 1/26/2014

What is A Mobile Ministry Methodology

The Mobile Ministry Methodology is a framework designed to assist individuals, ministries, and organizations determine the value, prospects, process, and successes of mobile ministry projects. Derived from SDLC methodologies, this framework is designed to keep the a singular goal in perspective despite tendencies for scope creep.

Please note, this is a framework. Therefore, activities within each phase might differ depending on the project. That said, the phases are quite rigid in keeping the focus of the project on both ministry and mobile applications.

Phase One: Determine if you are working on a mobile ministry project

The first step of this methodology is to determine if you are indeed working on a mobile ministry project. While it might seem that any project utilizing mobile devices and services is a suitable ministry project, the determining of whether it is a mobile ministry project falls towards whether the goals and activities within the project affirm the definition of mobile ministry:

Mobile ministry is the skillful use and application of computer technology classified as mobile for the context of fulfilling the religious designation of forwarding the proclamation of the key ideals and history of the faith, following form to and innovating on top of cultural and faith traditions within applied contexts [source]

(short version of definition)

The skillful use and application of mobile computer technologies for the fulfilling religious practices [source]

If your answer to this question is that you are not working on a mobile ministry project, this methodology and process will not be helpful to you. If the goals of your project would like to line up with ministry, as well as keeping that technical component of being mobile, a good place to check the motives and goals of the project can be found using the following Biblical references:

Deut 6:1-9
Matthew 28:18-20
James 1:22-27
John 17:20-26

Phase Two: Identifying the Frame for Mobile Ministry

There are several contexts in which mobile technologies have been used, or mobile behaviors tracked and observed. However, all of these are not specific illustrations of ministry (faith-building, faith-tradition extending, faith transformations can all be used as terms here). When mobile intersects with ministry, and the resulting actions are a change in behavior towards both technology and faith, then we can say that mobile ministry has occurred. MMM’s investigation and logging of activity in this space has identified these contexts (displayed here in their primary and secondary frames, linked to articles published here which correlate):

Phase Three: Identifying the Primary Focus for Mobile Ministry Activity

Activities within the previously mentioned frames of mobile ministry have engaged in one or a combination of three focus areas:

Devices
Services
Experiences

Previous discussion on these.

The focus is determined by the core and learned competencies which area needed in order to direct the mobile ministry effort. Many mobile ministry projects will involve two or all three of these at some junction, but the primary focus clarifies how in the later steps you can better identify gaps, resources, and implementation items.

Whether you are using one or all three of these layers, it is helpful to have within your project person(s) which have specific knowledge of the devices and their capabilities, the programmable and political natures of the services to be implemented, and/.or then a definition of the experience for users, administrators, operators, developers, and any other stakeholders. Within these layers of mobility are a wealth of forks which will determine the success or failure of your project if they are not accounted for at this junction.

Engaging the Project Activities

Once you have identified the framing and focus, the methodology begins to take place. While this might look different for specific outfits, the software development lifecycle (SDLC) methodology actually grounds the following phases of the methodology/process:

Establish the Three Pillars
Design and Test
Implement
Support, Report, and Reinitialize

Phase Four: Establish the Three Pillars

The first phase for the mobile ministry methodology involves what we call the three pillars: goals, issues, and resources.

Goals: setting a specific project goal for the project (multiple goals introduce variables harder to solve down the line); the goal should fit within a single mobile ministry frame, and have its mobile ministry focus clear upon statement
Issues: assessing the gaps (problem statements) of which if not solved, will cause the project (not simply expectations of the stakeholders) to fail. Issues might include the expectations of stakeholders, however, I would caution to making sure issues relate to the goal, and why implementation of the project will not perform as expected.
Resources: your people, processes, and tools which are readily available, or available with little extra effort or expense, that will assist you in completing your project. If you lack the resources (people, processes, or tools), then your primary issue is that of a lack of resources, not costs, time, or reach.

This would be similar to the project initialization and analysis phases of an SDLC/Agile methodology. It is within your dissection of the issues and and resources in which an analysis of the feasibility of your project will come to light.

Phase Five: Design and Test

Design and Testing should happen in concert with one another. It will be clear after the identification of the goals and issues what exactly needs to be focused on. Design should therefore take place in two phases – staging prototypes/examples and test-ready prototypes/examples. I am personally of the opinion that you spend more time refining the design than testing multiple iterations, but I know of many people having different philosophies here. I’d also recommend that any design and testing (especially if we are talking applications, software, and workflows) should take place with live data, and not dummy data.

Testing is about whether you are making realistic steps towards your goal, and have you developed an experience with your product to match the expectations after that goal is met. Anything that you are testing that does not have direct correlation to solving the issues which prevent your goals from happening should be dismissed (or in some cases, lowered in priority). Testing should also be designed to correspond to the availability of your resources in concert with how the results of the testing knock off all or some of the issues raised in the previous phase. There is potential for projects to spoke into additional requirements or opportunities as a result of the testing/testing data, so I would recommend that anything learned that does not positively effect your specific goals, be dropped for another project or future iteration of the current project.

The testing scripts should be designed so that they can be used in the Post-Implementation phase for reporting and support needs.

Phase Six: Implement

Implementing a mobile ministry project can be a difficult proposition. If this is an application, implementation might look like a slow-beta period, or a larger “let’s see what happens” kind of release. When it is a business process, implementation cannot afford such slow releases, and usually includes additional time and resources towards addressing items that could not show up in testing, implementing training, and finishing the reporting queue.

Your public feedback queue and media channels should be established and utilized at this point. Mechanisms such as Twitter, Facebook, Get Satisfaction, etc. are excellent for acquiring and monitoring specific feedback, while also lending a (hopefully) positive light on your ability to manage the roll-out of your product.

Phase Seven: Support, Report, and Reinitialize

Supporting your product includes having the appropriate documentation (text, video, etc.), publicity support, and consistent presence (support forums, email channels, etc.) which allow you to take in and categorize compliments and issues related to the implemented iteration of your project. Support does not necessarily include fixing all of those items which are brought to your attention – some items need to be input into the queue for re-initialization into another project.

As with your testing queue, the reporting structure that you use to watch usage, trends, and spot potential problems down the line should be in place here. Your report data might come from server logs, emails, or a combination of several streams of data, to which are collected in a regular report by which project managers an stakeholders can have a concise view of the project as it related to the specific goal.

Reinitialize means that you’ve met enough the goals of your project, and due to the data gained within the design, testing, implementation, or support/report streams, that you have an update to the project that you can do. Again here, the goal needs to be specific, but also not deviate greatly from the original product’s goal. It is not uncommon to go back to the drawing board and rebuild at this point.

Review of the Mobile Ministry Methodology Phases

Is this a mobile ministry project?
Frame the mobile ministry project (six areas)
Identify the primary mobile ministry activity’s focus
Establish the Three Pillars (Goals, Issues, Resources)
Design and Test
Implement
Support, Report, Reinitialize

View these phases in a graphical process map:

This process map was created in Google Docs for collaborative purposes. The Google Docs version will always be the latest iteration of this.

Items Not Seen In this Methodology

This methodology has been designed to be very generic. How you or your team manages their tasks, template documents, or other assets is not the point of this methodology. It is a framework to assist you/your team to understand from the outset of the project how to focus your efforts without losing focus of the faith and technological implications of your product. If at the end of your project, you have clearly demonstrated that you have forwarded some/all of the key ideals or behaviors of your faith tradition, then you can successfully say that you have engaged within mobile ministry.

If you have any comments or questions towards this methodology, please do not hesitate to email or send a message via Twitter. Its my expectation that this methodology will enable groups, such as those involved within the Mobile Ministry Forum, better identify successes, challenges, best practices, and other aspects of mobile ministry that have been hard to define and implement.

Associated Resources