From Office 365 Admin Site …
We’re making some changes to SharePoint Online pages
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!
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.
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
Here are some factors that can influence the selection and efficacy of a project management approach for a given project (or musical performance):
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.
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.
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!
David Remillard, Principal
Future Technology Group, Inc.
waterfall : classical :: agile : jazz
Although I do love “magical” thinking, the new NextGen portals, Groups, and Delve don’t eliminate the need for a strong SharePoint architecture in Office 365. At least at this point in time, that kind of thinking is not just magical … it’s also wishful!
Everybody knows that good foundations are important for houses, but did you know they are also critical in Office 365? Without a unifying architecture, the best you can achieve in O365 is a collection of point solutions. Perhaps not surprisingly, the biggest part of building that foundation has nothing to do with technology.
As you probably know, the biggest factor in using technology in business is not the technology itself. It’s people! And the same is true of the level of success you can achieve with Office 365. For example, you can’t have a unified approach to using Office 365 if you don’t have a unified vision in fixed in the minds of your people. Continue reading “SMB’s: 10 Steps for Creating a Unified Foundation in Office 365”
In 2011, Google’s cloud apps were in full swing and in fact it was Google’s success in the cloud at that time that helped Microsoft find its own brand of “cloud religion”. The year 2011 marked the beginning of a distinct (some would say artificially induced) cloud surge that continues to this day. Continue reading “Ex-centric Cloud Migrations”
FTG is proud to announce our recent partnership with IntraLearn Software!
In our more than 13 years of delivering custom SharePoint solutions, we have seen a huge void between large-scale eLearning software and smaller point solutions. IntraLearn’s informal learning software, called NanoLearn™, bridges the gap between “current information” and traditional courseware by drastically reducing the time and effort to keep people up to date on items such as processes, policy changes, best practices, and training requirements.
NanoLearn is integrated with SharePoint so you can leverage the platform you already have while delivering significant new eLearning capabilities. FTG can help you achieve your eLearning goals with a custom designed NanoLearn™ solution seamlessly integrated into your SharePoint environment.
For more information, or a live demo of NanoLearn™, please contact FTG. AND … if you’re at SP TechCon in Boston this week, be sure to stop by the IntraLearn Software booth and check out NanoLearn for yourself!