Emerging technologies are changing the dynamics of project team leadership and communication. And the way people have begun using mobile platforms is presenting some challenges. 

Prior to 2006, mobility had a very narrow landscape. Organizations that allowed their work force to have cell phones were usually restricted to one carrier, platform and equipment model. The majority of these phones were used for e-mail and conversations. 

Fast-forward to January 9, 2007 and the introduction of the iPhone, which introduced users to a world of new mobile capabilities.

While users immediately wanted to start using the iPhone at work, IT, security and cost issues made it impossible for many to do so. And to compound the problem, additional devices continued to appear with exciting, productive new features.

Over the last few years, many organizations have caught on and begun to take advantage of these mobile work force capabilities. Such resources have introduced many intriguing possibilities for project managers as well.
 
But this also means that now project teams are working across multiple platforms with unique requirements and configurations, which can cause performance and compatibility issues.
 
Some organizations are taking such steps as implementing mobile application program interface (API) layers in their infrastructure, referred to as "Mobile Enterprise Application Platforms" (MEAPs). They allow users to run software shells on their devices and overcome platform differences while providing access to disparate tools.
 
Other organizations have simply decided to continue to limit their work force to one standard device, choosing to take advantage of some new device capabilities and sacrifice others. Because this challenge is in its infancy, we've yet to see a solution.
 
Can all of your mobile project team members effectively interact with conflicting mobile platforms? If not, do you have a plan to mitigate this?  How is this situation affecting your project team?

On teams that work in creative services, like those found in advertising and in consulting agencies, often the person who serves as the project lead is not a project manager. 

This situation can be very tricky for a truly robust project manager who provides -- or wants to provide -- strong leadership and guidance to the team. It can lead to conflicts of interest and power struggles that can leave team morale in shreds.

When you see project managers in these environments, they've typically been relegated to a more administrative function. They essentially provide resource scheduling and reporting on data such as project profit and loss, rather than being empowered to provide much true leadership. (I discussed this in a little more detail in my first post.)

So should we eliminate the project management position and have the creative leads or account managers take on those responsibilities? Well, no.

Companies that attempt to eliminate the project management position from their ranks are ultimately just pushing this responsibility to other members of the existing team. Those members may believe they are able to take on the role of project manager, but more likely are too busy with their current responsibilities. Not to mention, they are nowhere near as knowledgeable or skilled in project management as they would like to believe.

The challenge lies in the perception of what it takes to manage and lead a project team from start to finish. If you were to ask your creative team or your account team, I'm willing to bet their description of leading teams would be inadequate. And much of the job they describe will be tasks they simply don't have an interest in performing.
 
So what do we do in these situations?

To me, the answer lies in accountability. If creative or account teams are going to claim leadership positions on projects, they need to be clearly identified by senior management as owning of the final, holistic project outcome. These project leaders must understand that their success -- and the project's success -- is tied directly to their ability to make all of the parts come together, even when many of the parts don't fall squarely in their functional purview.  

Have you experienced this kind of conflict? How was it resolved?