Mobile Challenges for Project Management: The Human Factors

In part one of this article, The Project Factors, we looked at the unique impact working in a mobile environment can have on your project. We talked about three areas: device support that can quickly get out of control without a thoughtful strategy, unique challenges with device purchasing and storage, and the importance of finding out store submission requirements and applying them to a project early rather than later. In part two, we will look at more mobile-related challenges to be aware of.

Ergonomics
If you work on a mobile device for any length of time, you'll start to notice that you're experiencing pain or discomfort. We have fantastic equipment to help us as we use computers—ergonomic hardware, monitor arms, adjustable desks, comfortable chairs, and all kinds of devices to help us deal with the problem of sitting in front of a computer all day. In the mobile world, we don't have that support. Try using your smart phone for a half hour or an hour straight, and you will soon realize that smaller devices cause more strain and discomfort more quickly than a computer. You can't sit at an ideal posture, and your body will compensate when you are interacting with a small device. If you use a small device for any length of time, notice the tension developing in your hands, hunching of shoulders and back, and eyestrain.

If people feel strain from using the devices, they aren't as productive. You can also burn some team members out, particularly testers or people who are doing frequent demos. It's important to monitor time and encourage people to take walks, stretch, and do whatever they can to reduce the ergonomic strain that is inherent with the devices. I asked an ergonomics consultant for mobile ergonomic advice, and the consultant was shocked that people would use the devices for longer than casual, short bursts. While you can offset device interaction somewhat using emulators on development machines, you also need to work with the real thing. One day, the ergonomic community and tools will catch up, but, in the meantime, watch your team members and their scheduled time using the devices. They just can't work as long on mobile devices as they can on computers. Some teams use an "ideal day" in their estimation and planning. If you use a six-hour ideal workday for hands-on technical work on computers, lower that to account for ergonomic strain when using the devices. Start with 25 percent less than your daily hour count, and work your way up or down from there.

Health
Mobile devices on development teams tend to be handled by everyone on the team. When cold and flu season hits, there is a danger of people getting sick. We tend to be more careful about keyboards, door handles, and things we are used to trying to keep clean. And, even on teams that use pair programming, you won't have a day with every team member touching your keyboard. However, this can happen with mobile devices because they are so small and easy to pass around. If you use a different device each day, you can't be sure who used it last and whether it is clean or not. It seems that every software development team has a "patient zero"–someone who gets sick more often, comes to work sick, and spreads sickness to teammates. On a mobile development team, germs and pathogens can be shared much more easily and much more quickly: A sick team member handles one or all of the test devices, goes home, and other team members touch those devices and get sick as well.

It is important to consider a conscious practice for minimizing the spread of pathogens between team members. Otherwise, you may be surprised at how quickly your team gets sick. Here are some practices I've used on mobile projects to avoid health issues:

• Supply hand sanitizer to each team member and encourage its use before and after using mobile devices and computers.
• Wipe devices after use with a cleaner. We used rubbing alcohol.
• Limit usage to team members, and store devices in clean, dry locations so they aren't sitting around picking up food, spilled coffee, pathogens, and other things from desktops.
• Remind people to wash hands frequently.

I was quite surprised at how much of an impact those simple steps had on reducing the spread of colds and flu. Prior to having a practice in place, we sometimes had most of the team off sick at the same time. This wreaked havoc with productivity and schedules.

Scheduling
All of the areas I have talked about have a potential impact on scheduling. If you decide to support a lot of devices, you have to develop for them, test them, and try them out with different carriers and network types. That requires time to set up devices with a telecommunications company, manage contracts, and, if required, get devices licensed for development. This can be time-consuming if you have a large target group of devices to work with.

When I am working with a mobile team, I plan and factor time differently than with traditional software. I scale down my available hours per day on mobile projects, and I always try to factor in time for uncertainty. The devices take more time to set up for development and testing, and there is a learning curve for adjusting to new tools and hardware versions, not to mention licensing or maintenance work. A surprising amount of time can be lost if devices aren't available–batteries die, communication or data contracts and licenses expire, cables go missing, and devices are "borrowed" by other teams. Not paying close enough attention to application store submission requirements during development can result in submission denials, and sometimes several attempts are required before you get it right. People get tired and uncomfortable more quickly using mobile devices than using computers, so they have fewer hours in a day that they can work steadily on the devices. Loss of work time due to sickness also has a larger impact than you might expect.

With a bit of planning and careful thought on these issues, you can still estimate accurately, but it isn't a "copy/paste" from a software project.

Read part 1 of this article at  Mobile Challenges for Project Management: The Project Factors