More posts in Nontraditional Project Management
Well, you certainly responded, not only in comments on the blog but also through emails and on Twitter. Your responses were very helpful and well-thought-out.
After reading your feedback and doing some research, I came to the conclusion that crowdsourcing can be a very effective tool. But only if it's used for a well-defined, focused portion of a project.
Crowdsourcing generally works best when you need a sampling of input from a large population. This can include activities such as requirements gathering, securing non-rights-protected content or a resource donation (such as computer bandwidth). Some mentioned software testing as a crowdsourcing activity. In this case, it's no different than what companies have always done when their products go "alpha" and "beta." People are simply slapping a new label on an old activity.
In any crowdsourcing scenario, the activities must be considered voluntary. There must be no compensation or contracts. And project participants must have a clear understanding that any contributions - tangible or intangible - are the property of the entity soliciting the input.
My rule regarding compensation for work could potentially be broken through a contest approach such as the Netflix Prize project, which focused on algorithms to enhance the company's ratings system. But activities like these would have to be tightly managed.
Are you or your company evaluating whether or not to foray into crowdsourcing? What types of projects will you use the activity for?
I understand the premise: Tasks are essentially outsourced to a large group of people through a call to action. (For more, see "The In Crowd" in the June 2009 PM Network®.)
This seems like a project manager's worst nightmare. The requirements and quality management alone must be a huge undertaking:
- How do you ensure a team of people who aren't getting paid remain focused enough to see your project through to completion?
- How do you ensure no one is trying to game the system?
- How do you reward those contributing more than others?
With many highly visible crowdsourcing projects, for example, there seems to be a lot of press about individuals within the "crowd" who ultimately feel cheated or used for their skills, having been inadequately compensated -- or not compensated at all.
It looks like you take a big chance when you sign on to these projects, given that there's usually no contract to fall back on. I imagine this risk goes both ways.
I hope this will serve as a conversation starter. What does your organization think about crowdsourcing? Have you ever participated -- or managed -- a crowdsourced project? I'm very interested in hearing the challenges and victories out there around this approach.
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?
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?
I held my tongue during the formal pitch, but made a point to ask the presenter a few questions after the meeting. Primarily, I wanted to know if he had heard of the triple constraint. The "iron triangle" as some refer to it, defines three pillars: cost, scope and time. It asserts that you have to prioritize the three with an understanding that trying to have all of them at the same time compromises quality.
Some assert that several additional factors come into play when discussing a project's success. I agree with this, but I disagree with removing the triple constraint model from training, as I believe it's such an easy concept to teach, understand and enforce.
My confidence in the triple constraint made it hard for me to believe that anyone had truly convinced themselves they could beat what is, essentially, physics. But sure enough, I got a very firm response from the organization: "We are able to deliver this service because we take an agile approach in our production processes, making us more efficient and thus able to deliver more value for the customer."
Confused, I pressed a little further.
"As I understand it, agile as a methodology does not allow you to overcome the basic physics outlined in the triple constraint. Agile simply prioritizes the tradeoff as one of scope rather than time or quality," I said.
Of course, it wasn't a discussion I was going to win in this setting. Looking around, I saw that the speaker's entire management team had bought into the theory and were smiling proudly at their triumph. I let it go. But it struck me how much confusion still seems to be out there around the triple constraint and the ability of newer methodologies such as agile to overcome it.
How many of you have had your management tell you to explore agile as a way to get your current project work done faster without sacrificing any of the three pillars? And how many of you still use the triple constraint to help you explain the basics physics around project execution?
In John Stenbeck's session, "Agile PM Mastery in 60 Minutes, Guaranteed!" he had a fantastic way of boiling down the essentials and explaining them in a way that traditionally trained project managers easily understand.
Many agile proponents will tell you that the methodology will work within almost any environment that traditional waterfall methodologies will fit. In fact, there's one comment on my previous post suggesting that the issues that I've described -- like needing faster time to market and the ability to address fluid requirement -- would be addressed by implementing agile.
I see a big gap, though: staffing. Agile works best when you have a dedicated team for the life of the project -- or at least the sprint.
But many "consulting-structured" organizations rely on their ability to maximize cost benefits by pooling resources. This means assigning one person to two or more projects at a time. That strikes me as a big issue for an agile team structure.
So, in a non-traditional environment with team members who aren't always dedicated to one project, what are your options in terms of attempting to implement agile?
I look forward to hearing your thoughts.
In my last post, I described the challenges of maintaining project management rigor in an environment where people are primarily in creative service roles. It appears I hit a chord. A few of you have commented and want to know how I've handled the situation.
Well, first I will say that I believe we will never reach 100 percent compliance with the project management standards you'd expect to find at NASA or a construction site. Creative work is not an exact science and it requires some very non-linear thought and approaches. It can be very hard to pin down a repeatable formula for executing these kinds of projects.
If there are specific tasks you cannot predict or that don't fit into a prescribed methodology, people tend to simply operate by intuition. The first thing you need to do is to look for the wins. Where in the process can you continue to provide rigor and discipline to help keep the project within boundaries, while avoiding the appearance of overly constraining your teams?
We have done this by creating as flexible a methodology as we can. As a whole, it closely follows the tenets set forth in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). The software development life cycle serves as a foundation: planning, discovery, design, build, test, implement, support, rinse and repeat.
The difference comes in our application. For any given project -- whether it's a marketing e-mail, interactive web banners, mobile applications or full site development -- we have fundamental requirements that don't change. All projects must have a timeline, for instance. And all projects must have a scope, a set of requirements approved and reviewed throughout to ensure we're on target.
Beyond that, it's the diner's choice: Does a four-week e-mail project require a formal matrix of approvers? Probably not, though it would help to have a short list of final approvers. Does an interactive banner need a content matrix or a formal technical architecture? It all depends on what the team needs.
How has your organization tailored its project management approach to account for the unique needs of its project teams?
Agencies and clients who spent the past century perfecting project management functions around print, broadcast and direct mail are being forced to readjust systems to the complexities and rapid-fire change of digital marketing.
Two worlds are colliding.
Digital teams view process as an essential science. The project manager is the team lead that everyone depends on for risk management, communication, client management, profitability and ultimate success.
But traditional advertising teams tend to see process in a different light. They look to their account and creative directors as the team leads. The project manager, while important, often takes on a more administrative role, ensuring resources are in place, schedules are communicated to vendors and paperwork is complete.
When I took on my first role as a manager of a project management office (PMO) for a large ad agency two years ago, the difference between these two worlds became vividly clear to me in a conversation with one of our creative directors:
Me: We need to translate the client brief into a statement of work so we have a specific record of what we'll be delivering.
Creative Director: We don't know what we'll be delivering yet.
Me: Then we should meet with the client to understand business requirements and document them for sign-off.
Creative Director: I know what the client wants, but I'm going to tell them what they need.
Me: Then how do I budget resources, document our success metrics and track the progress of the project?
Creative Director: That's your problem. We'll let you know when we get there.
It was an eye-opener, to be sure. But eventually I was able to adjust my view of what the team was trying to achieve. I set a baseline process to create a flexible methodology that would allow us to pull in elements that were appropriate, and not commit time to requirements that didn't lend a lot of value.
Some of these changes included a flexible, scalable methodology that allowed teams to pull in elements relevant to their process. This allowed them to:
Have you ever been in a situation like this? What have you done to maintain rigor in your environment when the project at hand did not readily lend itself to the traditional project management processes?
- Maintain efficiency while ensuring consistency across the agency
- Reinforce the "triangle of truth" (good, fast, cheap) in the scoping process to ensure profitability
- Implement grassroots efforts to reinforce the importance of maintaining rigor in the process through tactics like "Lunch and Learn" sessions to discuss our process and the risks inherent in not following it.