Category: Uncategorized

I created two 2010 workflows using SPD 2013. One sends emails and the other changes permissions and they both operate on multiple people who are specified in a multi-select person field in SharePoint. Turns out, the way you specify the return values is different for each scenario (but not how you think).

Replace permissions on an item … for this action, returning a multi-select as “Email Addresses, Semicolon Delimited” didn’t work. I changed the return value to “Login Names, Semicolon Delimited” and it appeared to work. (BTW … none of this is documented in the product help or in online documentation for the product, so it’s trial and error all the way). I thought this made sense as setting permissions may be more related to login names than email addresses … BUT NOT SO FAST …

… it only worked when a just one single person was entered into the form field. When multiple persons are entered into a multi-select field, the workflow would crash. What is up?

After some further Googling, and trying various suggestions that didn’t work, I found that someone had gotten around this by setting the Return field as STRING! This suggestion worked! I’m sure there’s a reason, but it’s not very intuitive, to say the least. Not sure why it works, but it does.

Might be worth a try if you need to set permissions using a multi-select person field.

When designing, building, implementing, and supporting business systems, most modern project management styles and methodologies seem to fall into two main styles: waterfall (traditional) and agile (modern). The contrasts in these two styles seem to run remarkably parallel to the similarities and differences between classical music (traditional) and jazz (relatively modern).

Most of us have probably worked on projects where everything and everyone just seems to click, and also other projects that, in spite of everyone’s best efforts, just don’t click at all. It’s an awesome feeling when the team is “firing on all cylinders”, but when the wheels of progress are grinding or even completely jammed, it’s totally the opposite experience: team members can become frustrated, communication can falter, precious time can be wasted, quality can suffer, and all of these can negatively impact the most important success criterion on any project … client satisfaction.

The selection of a project management approach has an outsized impact on any given project’s chances for success because it’s the framework on which the project is built. The selected approach is also often the basis for a statement of work (SOW), so how the project is structured can also become a legal commitment. So it’s important to structure it well. And just like different kinds of music and necessarily good or bad, it’s not that any one methodology is inherently better than the others, but rather how well the chosen approach fits the realities of the project (or performance at hand).

So let’s take a quick look at some VERY BASIC classical and jazz music concepts and see how they relate to project management. I don’t believe you’ll need to be a musician to appreciate the metaphor, but it probably wouldn’t hurt to at least have a general interest in music.

Disclaimer: This post isn’t meant to be an academically rigorous work from either the musical or the project management side. I just wanted to share a musical metaphor that I’ve used for years in the hopes that it might help illustrate some project management dynamics that can affect a project and all too often fly under the radar. Enjoy!

Classical Approach

In general, classical music is extremely well-defined in advance. This approach to music scales easily from small groups to large orchestras because everything is defined in advance in complete detail. For example, here’s a typical page of classical music … it’s the first page of Edward Elgar’s Serenade for String Orchestra (Opus 20):

Like a typical waterfall project plan, each instrument (resource) has its own slot on the overall timeline which is read left to right and wraps to the next line when it runs out of space. Vertical lines represent a repeating time interval, and notes that appear above each other are intended to happen at the same time.

If you want to hear what the above sounds like, here is a video of the above Serenade for String Orchestra. Interestingly, because of the level of detail in classical music, the above page of music only covers the first 27 seconds of the video! (Similarly, waterfall projects typically have more documentation to support the detailed definitions that need to be completed before building can begin).

OK, now compare this simple waterfall project example to the classical sheet music above:

Notice the similarities in a classical score and a typical waterfall project plan? They are both on a timeline. They both define what precisely should be performed, which resource (or musician) will do it, when they will do it, for how long, which tasks/musical notes will happen simultaneously, and in what order from start to finish. As with classical music, traditional waterfall methodologies provide a more structured and linear approach where each phase is clearly defined and completed before the next phase can begin.

Jazz Approach

Although it uses the same notes and instruments as classical music, one major difference with jazz is that it deliberately does not define everything up front. The jazz methodology is to provide the essential outline of a piece of music and rely on the band members’ experience and expertise to build on that outline and create the finished product in real time. For example, here’s a page of jazz music notation for the song Autumn Leaves by Johnny Mercer (indicative of their purpose of enabling exploration and improvisation, written jazz music for a single song is often referred to as a “chart”):

Like the classical sheet music above, there are notes and vertical timeline markers. But this time, you don’t see separate notes for each instrument. There’s only a single line of notes that defines the melody. No other supporting notes are specified. Instead, on the same timeline, there are letters (e.g. A-7, D7, etc) that indicate the chord (i.e. other notes played simultaneously) that goes with the melody at that point in time. There are a countless ways to play each chord and rhythms with which to play them, and this notation doesn’t specify any of it. All of the band members, including piano, bass, drums, sax, trumpet, etc. know from experience and knowledge which specific notes to play and which ones sound best in the context of the current moment.

Like agile project management, jazz often has built-in iteration. Very often, a jazz song starts with the band playing the original song melody once or twice. Then, the song repeats with one or more musicians taking turns improvising (“soloing”) while iterating on the same song structure. Finally, the band plays the song’s original melody one last time to end the song. Often the number of iterations is also not pre-defined but continues until the song feels done to everyone’s satisfaction. During the performance, jazz musicians listen intently to each other, takes cues from one another, and support each other as they both define and create music in real time. Success is defined solely by the quality of the actual outcome.

Here are two versions of Autumn Leaves. Although it’s the “same song” there are huge stylistic differences such as the specific instruments in the band and the precise selection of notes and rhythms. It’s also interesting that one is about twice as long as the other. This is due to the number of song iterations that the musicians decided to perform. That wouldn’t happen in classical music. But it’s totally normal and encouraged in jazz.

Like jazz, agile development methodologies like Scrum, Kanban, and iterative project methodologies like RUP all address the need to create and adapt “on the fly” while providing a clear framework that supports the kind of rapid progress that depends on skill, feedback and interaction. Two characteristics that agile approaches share are iteration and concurrent design and development. This RUP diagram shows this dynamic in action. Notice that as time goes by there are iterations (I1, E1, E2, C1, C2, etc.) and that modeling, requirement, analysis & design, Implementation, testing and deployment are all happening concurrently during each iteration.

Although there are differences among them, agile methodologies in general all provide a high level framework that enables the active participation and creativity of all roles simultaneously. Focus is intensely on the current iteration. The specific features to include in the current iteration and how they are built are determined by real time interaction of all players.

Waterfall vs. Iterative

Key Factors

Here are some factors that can influence the selection and efficacy of a project management approach for a given project (or musical performance):

Design … The more that details need to be designed and approved up front before construction can begin, the more it’s likely to be a better fit for a waterfall/classical project. If a project requires real-time team, cross-team creativity and interactivity then lean towards an agile/jazz approach.

Size … In general, the bigger the project, the more likely it’s a candidate for a waterfall/classical approach. (There’s a reason why symphony orchestras don’t just “jam” … they plan it out and write it down).

Iterations … If the client wants to release new functionality incrementally, then an agile/jazz approach is likely a better fit. It’s also possible to build some iteration into a waterfall project, but iteration is a given for most agile/jazz approaches.

Hybrid … If different project phases have different scales, then you may be able to treat them differently to good effect. For example, designing and developing a software feature can be done agile, while rolling that software out to 5000 users across 8 time zones can be done waterfall.

Culture … For a variety of possible reasons, some company cultures are simply more comfortable with either waterfall or agile methodologies. Sometimes their preference is a requirement, but it’s always worthy of consideration.

It seems that project management “fit” comes directly from the combination of the above realities and the requirements of the project at hand. If the project is ripe for an agile approach, and you impose a waterfall management style, you not only create more work for yourself, but more importantly, you may actually impede the team’s ability to design and build, which can result in a ding on timing, quality and morale. Conversely, choosing an agile approach when the project has strong waterfall indications can also kill team effectiveness and cohesion when the required controls and explicit task definitions and timelines that are required by the realities “on the ground” are not there.

Human Factors

Somehow, even for non-musicians, it seems fairly easy to understand that some people can play classical music beautifully while being totally unable to improvise on a popular tune and vice versa, or that some people can “play by ear” while others only “read music”. It’s almost intuitive that while there are commonalities, the types of creativity and specific skills are different in classical music and improvisational jazz. However, the fact that there are differences in people’s ability and comfort level with waterfall or agile project methodologies seems to be less easily appreciated or understood.

Individual affinity for a particular project management style may be a matter of “nature” as when some people just seem to have a “knack” for one thing but not another (e.g. analytical ability, creativity, introvert/extrovert, etc.). Other differences may be based more on “nurture”, or experienced-based, and develop as a result of a person’s early project experiences (both positive and negative).

There is an old, but interesting pop-psychology book called The Corporate Steeplechase whose author claimed to have “explored the business lives of 5000 Americans over a period of 25 years to identify the personality traits that lead to their success or failure at work.” To summarize his findings … people who joined a large, established company “right out of school” learned to value things like not going outside the job description, respecting the hierarchy, and the importance of work/life balance. Those people whose first job was with a small, entrepreneurial company learned to value different skills like thinking outside the box, doing more with less, wearing many hats, challenging assumptions, etc. Then, when these people changed jobs, they would invariably have difficulty in transitioning whether they moved from a large company to a small entrepreneurial one or vice versa. This sometimes even resulted in full-blown career crises when skills and methods that worked in the prior company not only didn’t work in the new environment, but were actually seen as dysfunctional, destructive and uncooperative by other team members.

So similarly, people who have previously participated in successful waterfall or agile projects may be molded by their experience and learn to value and develop skills that are essential in one context but detrimental in the other.

Next Steps

Regardless of the specific methodology or tools you choose for your projects, having a deeper appreciation for the qualitative differences between agile/jazz and waterfall/classical can help project managers and team members alike.

As a manager, the more you start to notice this jazz vs. classical dimension in project management, the better you may be able to craft a plan that fits the project at hand. You may also develop a better feel for how much detail to put into the plan, and when and what not to plan.

And with a deeper understanding of the people side of the equation, you may be better able to help team members bridge the gap in their perceptions and understanding of the project and their role on the team … for example, sometimes helping jazz players to provide a little extra structure or encouraging a classical player to build in some time for experimentation.

Good luck with your future projects (or performances). And please let me know if any of this “resonates” with you!