Tag Archives: layers of mobile

Practical Mobile Ministry


When my recollection of history was a good bit clearer, we could have a discussion about the discussion of ministry where one part talked of the need for minsitry to be embedded within the practical needs of the community. Things such as establishing schools, businesses, hospitals, etc. are seen to go hand-in-hand with the proclamation of the Gospel. The other side of the discussion presents the proclamation of the Gospel as the do-first mandate. Where its more important to declare and convince the community on the perils of living without Jesus, and then letting that be the avenue by which practical and justice needs are met. The discussion of mobile in ministry follows the same lines. And while my perspective of ministry lies more with the former than the latter, I do understand and shift context according to the expressed needs of the moment.

That is probably why this discussion of China’s approach to developing economies on the Africian continent stuck out a bit. The fruit of China’s actions seem to be improving the ability for the majority of Africians, while also granting China the access to the raw materials and people they desire for their activities. Here’s a snippet of that article at the Harvard Business Review:

…And yet, it was the United States that peddled democracy and human rights — a.k.a., broadly speaking, ideology. Faced with the negative fallout of that, Secretary Clinton has recently sought out a more balanced approach, focusing on business (and opportunity) over human rights (and hectoring).

Meanwhile, the Chinese have kept building bridges, railroads, and conference centers. Ironically, it is the Chinese — not the Americans — who can make a compelling case that their focus in Africa has been not on spreading ideology but on the practical business of securing natural resources and creating future customers and trading partners…

Read the rest of How China’s Approach Beats the West’s in Africa at the Hardvard Business Review

The article raises a similar point though for us who pursue mobile ministry (#mobmin). Is the ideology of mobile ministry what you run after? Or, is it the opporunity to improve the practical lifestyle of people through the application of mobile tech (devices, services, or experiences) where your ministry opportunity lies? In both cases, what about mobile ministry remains practical in this age.

Mobile Ministry Methodology (v1)

For the years that I’ve been looking at this intersection of faith and mobile technology through the lens of MMM, one thing has honestly escaped much of the conversation around the topic: if this intersection is valid, then what do people do to get past that intersection and into some relevant demonstration of their faith. In effect, what’s the method to the madness?

Being able to devote much more time to MMM in the past two (2) years has granted my thinking and action spaces to do just that – figure out the methods and some streams of activity within them. You’ve seen this in part if you’ve followed this site for sometime and watched its evolution. In this post, I kind of want to pull all of that together into what amounts into a mobile ministry methodology. The goal of this methodology is to literally demonstrate the definition of mobile ministry in the midst of practice and application.

Mobile Ministry Sketchnote Mindmap - Share on Ovi

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
Mobile Ministry Methodology Process Map

  1. Is this a mobile ministry project?
  2. Frame the mobile ministry project (six areas)
  3. Identify the primary mobile ministry activity’s focus
  4. Establish the Three Pillars (Goals, Issues, Resources)
  5. Design and Test
  6. Implement
  7. 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

Building with Sticks, Connecting with Glue

glue,sticks, and clothes pinOver the past week(s), I’ve been working on answering some simple questions to address building pitch slides for the weekly 1M/1M public discussion. There’s a signifiant need for sales/marketing help for MMM, and getting through these slides has been rewarding and frustrating. We are really missing a lot of pieces of data we should have, and other parts are defined enough that it doesn’t fit normal modes of “building and marketing a product.”

The “product” MMM sells is the knowledge and underanding of making sense out of the points which connect mobile and faith activities. That’s not something easily bottled, that is, unless its sold as glue and not as the bottle. Now, to sell glue, you have to identify what things need to be present in order for that stickiness to take place. You’ve got to be able to say on your label what surfaces it works best on, where not to put it, and probably some hazard information in case someone misuses the glue.

For us, that means we aren’t so much as building apps and services, as much as we are identifying those points where devices, services, and experiences come together for a specific environmental condition at the intersection of faith and mobile technology. Unless folks already see that these two areas collide, they won’t be able to discern how best to glue them together. That’s how we get the term mobile minsitry, we are looking at this intersection of two areas that have some common points (communications, sociologiy, etc.) and what happens when they collide and both those common and uncommon areas get challenged.

The other day, I responded on a post for a developer at LinkedIn. The post didn’t identify a specific need for the developer, but did mention much about the organization (the usual HR boilerplate stuff) and then some toolsets/skills needs for the position. I made several assumptions about what they are looking for ending with a statement that perhaps they are looking for something less oriented to building and something more like glue. Now, I was corrected, and in that correction was detailed the specific need for that position, but it still came across as looking for glue, not someone to make sticks.

When it comes to mobile ministry, part of that identifying what it is you are offering (our case) or what you are looking for (the folks we tend to attract) is making this distinction between building and sticks. Sometimes, you might solely be on the side of building, and therefore a specs sheet of programming languages accompanyed with certain products might be the key. Other times, and usually what we see more often than not, is that people are looking for the glue. How does mobile stick best with wherever they are? Whether that’s reformatting videos, adjusting to the appearance of mobile on the ministry scene, or introducing less friction to a reiteration of a product, its more about the glue (what happens in between the points), than the sticks (the points)..

I’d wager that many of you have been using sticks like glue and wondering why you haven’t seen the successes you’ve wanted. May I make the suggestion that you find the jars of glue (who connects the dots within mobile and ministry), and then refocus your energies? You might find that with less building that you enable more sticking to your ultimate goals.

2012 Resolution #1: An App is Not A Strategy

Welcome to 2012 and Mobile Ministry Magazine (MMM). Since 2004, we’ve talked a lot about this intersection of faith and mobile technology and how this has often looked like applications. We’ve talked about the good and bad about these applications, what has improved, and what still isn’t being touched. And yet there’s there is a pervasive resolution that I think you should endear to any mobile ministry efforts for 2012: an application is not a strategy.

We’ll summarize how we come to such a conclusion in this article. Some of these concepts have been covered before, other parts not yet in enough depth to give you a means to continue. But don’t worry, as we encourage you to step into 2012 with your mobile ministry efforts, the goal of this article is that you address mobile ministry as a spoke in a larger wheel of your efforts, no matter where you are in the chain.

This article focuses specifically on these points:

  • What is Mobile Ministry?
  • What are the specific areas in which mobile has addressed a ministry context?
  • Is there anything consistently applicable across those areas of mobile ministry?
  • If applications are part of the solution, what else is there?
  • What are some resources for applying these points?

What is Mobile Ministry

Mobile ministry is the application of mobile devices, services, and/or experiences for the purposes of forwarding ideals and characteristics of a faith movement.

Mobile computing has a market-led definition (portable, cellular and/or WiFi-enabled computing devices which have screen sizes between 2.2 and 5in, and have some form of primary input that is not mediated by accessory-attached mice/keyboards). We take the stance that mobile computing devices can include any portable computer that is not designed specifically as a clothing accessory.

Mobile services include, but are not limited singular applications of cellular (voice, data, SMS, multimedia), Internet (browsing, email, IM, VoIP, Wi-Fi, GPS), and applications (including the tools to create and distribute, API structures/protocols, development standards/practices, etc.).

Ministry is defined as any activity which forwards the ideals and characteristics of a faith movement, that may be personally motivated, community organized, and/or governmentally implemented.

This definiton is intentionally not grounded on any one religion/faith, and has been [slightly] refined from its more academic-correct beginnings. Discussions towards refining this further should be a part of any conversations brokering mobile as useful in ministry contexts.

Specific Areas of Ministry Applied in Mobile
Over the course of seven years, MMM has observed six specific applications of mobile technology within ministry contexts. This doesn’t mean that there are not, or could not be others. Within these six areas, we have identified unique approaches combining devices, services, and/or experiences which create avenues for personal, media, and cultural transformation through faith-binding activities.

These six areas are as follows:

We will further define and illustrate these areas throughout 2012. Please refer to former articles and presentations on this subject in order to see some of the progression of these ideas. We will endeavor to link to articles tagged with these topics in order to best consolidate the discussion on this site towards these points.

Layers of Mobile
We are careful not to simply define mobile in the context of devices or development. There are three components which encompass the mobile environment which all need to be considered and included within the context that is mobile computing:

  • Devices
  • Services
  • Experiences

We will further define these areas beyond our initial exploration of these throughout 2012. Please refer this article/document for a direct linking to that discussion.

Applications and Beyond
It should be clear within what we’ve explained so far that defining mobile ministry strictly or specifically in the context of downloadable applications is incomplete. Applications are only a part of the usable toolkit for mobile within ministry endeavors. Streams in which mobile can be developed/sold/applied within ministry contexts include:

  • Software Applications
  • Hardware Applications
  • Voice Services
  • Video/Audio (Streaming, Downloads, Sharing, etc.)
  • Text (SMS, language transcription, etc.)
  • Downloadable/Streaming Media (APIs, content libraries, etc.)
  • Mixed Media (creation, distribution, specifications, etc.)
  • Security
  • Reporting
  • Personalization

We will further define these areas throughout 2012.

Resources for Moving Forward

Conclusions: An App is not a Strategy, But…
We will not debate the point that for many endeavors, the first door that mobile will open is that through an application store. However, the first door seen is not the only door available. Depending on what it is you are developing, offering, or enabling, an application might not be the best point of entry.

For 2012, consider your opportunities and challenges within ministry, and whether mobile is the best route. If it is, then you will want to start looking at where you sit in terms of those areas of mobile, and then whether you are targeting devices, building a service, or managing an experience. After that point, it becomes clear how you should approach mobile. It may very well be that you do need an application – but now it will have a specific target, you can begin planning and setting up your team and content appropriately. If it means you need to outsource the development of your mobile solution, you do so with knowledge of more than simply “make it work on this device.”

At the intersection of faith and mobile technology, what are you pointing towards? In 2010, don’t let your strategy (or lack of one) turn mobile into a dead-end for your effort.

Charting an Efficient Path Thru Mobile Ministry Initiatives

Mobile Ministry Mindmap Segment - Share on OviOne of the ways that MMM has been able to help organizations is in respect to breaking down and rebuilding points that influence mobile and other parts of communication events. We do this in part by working every communication issues thru a methodology born out of how we look at the layers of mobile: devices, services, and experiences.

Devices

Devices are agents and windows. What is most important to them is that ability for anyone to use devices for their most efficient and effective communicative purpose. That means that handheld mobiles (PDAs, phones, media players, etc.) speak towards a context of communication events that other mobiles (tablets, laptops, etc.) might not. Knowing the built in abilities and the perceived biases people have towards these gives one layer towards efficien communication. In a very real sense, if you don’t know the device’s abilities, then not much else matters for mobile ministry initiatives.

Services

Services are enablers. Look at services as a channel towards that expected end. They can exist in and of themselves, but the devices and experience design constrains their relevance and effectiveness. What’s usually the challenge here is knowing the bounds of the service inside of your communications needs, and then if it scales with the organic nature of communication behaviors. If it scales, or constrains, favorably, then the chance of a service becominng an integral part of your effort grows. However, service relevance is important here; what’s relevant to the IT administrator is not relevant to the stakeholder (except for cost and time to implementation). Don’t get trapped into making the more important than the other layers, don’t miss that it needs to be working for the Experience layer to be met positively.

Experiences

The Experience layer can be summarized by simply stating, “what are your goals?” Why is this technology, behavior, initiative, or function important to the overall mission of the organization? Is it an experience that is going to govern how others perceive your mission, Christ, etc.? What is the goal of the media transferred to the device? Can that media meet that goal, or is this a matter of planting and watering so that something later can manifest? Are you reaching too far trying to drive the experience? Or, are you not reaching far enough? Once that experience happens, are the persons or their devices evangelists for you, Christ, or something else?

Answering these three layers allows you to chart a path to a solution that’s more efficient than it is amazing. Sure, mobile ministry endeavors want to always “reach the world for Christ.” But, the reality is that the reach of any effort has constraints that you have to identify and then play within. If you will, the path is more narrow than wide, and your efforts have to respect those constraints to see the nets filled.