At the end of this month, Cloud Gate, a Taiwanese dance company, will celebrate its 40th anniversary with the performance of a new routine, "Rice." Its founder, Lin Hwai-Min, has received international recognition and awards, including the United States' Samuel H. Scripps American Dance Festival Award for Lifetime Achievement in Choreography in 2013, Germany's International Movimentos Dance Prize for Lifetime Achievement Award in 2009 and Time magazine's Asia's Heroes award in 2005.
"Rice" looks to be a culmination of the company's past four decades of work. But it could not have happened without Mr. Lin's talents -- and his arts management team. Their involvement allows the choreographer to concentrate on his creative work. It wasn't always like that; in the early years, Mr. Lin was responsible for teaching and choreography, as well as staging, marketing and fundraising. This left him exhausted and unable to work creatively.
Mr. Lin realized Cloud Gate had to develop a management team. Nowadays, the company has divided its operation into three parts. Firstly, the performance of the routines. Secondly, the training and cultivation of artists, whether dancers or choreographers. And finally, the promotion of dance and taking part in wider cultural activities. The three divisions overlap, forming a coherent program of work that defines Cloud Gate as an organization. This is very much like portfolio management, dividing organizational objectives into different projects or programs.
All of Cloud Gate's managers know they're there to allow Mr. Lin and the rest of the company to work creatively. They know their work helps fund performances for artists and also keeps Could Gate -- and them -- in work. This makes them both sponsors and key stakeholders. And since theater work is beset by a multitude of details, the managers have become skilled in tackling issues appropriately, discerning what is important for the business or for art. However, because ultimately they are part of a creative process, they know they have to be flexible in how they work with artists.
An impressive archive of routines also contributes to the survival of the dance company. Cloud Gate has accumulated over 160 dance routines. Combinations of these can be used to stage a performance anywhere in the world. Routines based on well-known Chinese literature or folk tales, such as "The Dream of the Red Chamber" and "The Tale of the White Serpent," appeal to Chinese audiences. Those in a more abstract style, such as "Cursive," delight European audiences. The inclusion of different routines into a performance helps Cloud Gate develop new audiences or maintain the loyalty of existing ones worldwide.
Mr. Lin also guides dancers' careers, cultivates young choreographers, and contributes to Taiwan's arts and culture. For example, Cloud Gate is the first dance company in Taiwan to provide its dancers with a salary and routine training. The company also regularly holds open classes and performances in all parts of Taiwan, using scholarships and awards to encourage young people to take up modern dance and choreography.
Mr. Lin has spent most of his life searching for this: a sustainable way to run an international contemporary dance company. And project, program and portfolio management have helped get him there, delivering inspiring results.
If you work in a creative industry, what's the role of your management team?
|In my previous post about whether crowdsourcing was worthy of all the exposure and hype, I asked for people's opinions.|
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?
|Can someone please help me understand the hype surrounding crowdsourcing?|
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:
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.
|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?