Skip to main content

Tag: Development

Business Process; A Thing of Beauty

Written by Suzanne Jane Maxted on . Posted in Articles.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model.  This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

Most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

businessprocess_1.png

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

businessprocess_2.png 

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

businessprocess_3.png

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘.  This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

Tackling Updates to Legacy Applications

Written by Cynthia Low on . Posted in Articles.

After 40 years of serious business software development, the issues involved in dealing with legacy systems are almost commonplace. Legacy applications present an awkward problem that most companies approach with care, both because the systems themselves can be something of a black box, and because any updates can have unintended consequences. Often laced with obsolete code that can be decades old, legacy applications nonetheless form the backbone of many newer applications that are critical to a business’s success. As a result, many companies opt to continue with incremental updates to legacy applications, rather than discarding the application and starting anew.

And yet, for businesses to remain efficient and responsive to customers and developing markets, updates to these systems must be timely, predictable, reliable, low-risk and done at a reasonable cost.

Recent studies on the topic show that the most common initiatives when dealing with legacy systems today are to add new functionality, redesign the user interface, or replace the system outright. Since delving into the unknown is always risky, most IT professionals attempt to do this work in as non-invasive a manner as possible through a process called “wrapping” the application, which is an approach to keeping the unknown as ‘contained’ as possible and interacting with it through a minimal, well-defined, and (hopefully) well-tested layer of software.

In all cases, the more a company understands about the application – or at least the portions that are going to be operated on – the less risky the operation becomes. This means not only unraveling how the application was first implemented (design), but also what it was supposed to do (features). This is essential if support for these features is to continue, or if they are to be extended or adjusted.

Updating Legacy Applications: A Formidable Task

What characterizes legacy applications is that the information relating to implementation and features isn’t complete, accurate, current, or in one place. Often it is missing altogether. Worse still, the documentation that does exist is often riddled with information from previous versions of the application that is no longer relevant and therefore misleading.

Other problems can plague legacy development, including the fact that the original designers often aren’t around; many of the changes made over the years haven’t been adequately documented; the application is based on older technologies – languages, middleware, interfaces, etc. – and the skill sets needed to work with these older technologies are no longer available.

Nonetheless, it is possible to minimize the risk of revising legacy applications by applying a methodical approach. Here are some steps to successful legacy updating:

 

Gather accurate information. The skills of a forensic detective are required to gain an understanding of a legacy application’s implementation and its purpose. This understanding is essential to reducing risk and to making development feasible. Understanding is achieved by identifying the possible sources of information, prioritizing them, filtering the relevant from the irrelevant, and piecing together a jigsaw puzzle that lays out the evolution of the application as it has grown and changed over time. This understanding then provides the basis for moving forward with the needed development.

In addition to the application and its source code, there are usually many other sources for background information, including user documentation and training materials, the users, regression test sets, execution traces, models or prototypes created for past development, old requirements specifications, contracts, and personal notes.

Certain sources can be better resources for providing the different types of information sought. For example, observing users of the system can be good for identifying the core functions but poor at finding infrequently used functions and the back-end data processing that’s being performed. Conversely, studying the source code is a good way to understand the data processing and algorithms being used. Together, these two techniques can help piece together the system’s features and what they are intended to accomplish. The downside is that these techniques are poor at identifying non-user-oriented functions.

The majority of tools whose purpose is to help with legacy application development have tended to focus on one source. Source code analyzers parse and analyze the source code and data stores in order to produce metrics and graphically depict the application’s structure from different views. Another group of tools focuses on monitoring transactions at interfaces in order to deduce the application’s behavior.

Adopt the appropriate mindset. While this information is useful, it usually provides a small portion of the information needed to significantly reduce the risk associated with legacy application development. A key pitfall of many development projects is not recognizing that there are two main “domains” in software development efforts: the “Problem Domain” and the “Solution Domain.”

Business clients and end users tend to think and talk in the Problem Domain where the focus is on features, while IT professionals tend to think and talk in the Solution Domain where the focus is on the products of development. Source code analysis and transaction monitoring tools focus only on the Solution Domain. In other words, they’re focused more on understanding how the legacy system was built rather than what it is intended to accomplish and why.

More recent and innovative solutions can handle the wide variety of sources required to develop a useful understanding and can extend this understanding from the Solution Domain up into the Problem Domain. This helps users understand a product’s features and allows them to map these features to business needs. It is like reconstructing an aircraft from its pieces following a crash in order to understand what happened.

Pull the puzzle together. The most advanced tools allow companies to create a model of the legacy application from the various pieces of information that the user has been able to gather. The model, or even portions of it, can be simulated to let the user and others analyze and validate that the legacy application has been represented correctly. This model then provides a basis for moving forward with enhancements or replacement.

The models created by these modern tools are a representation of (usually a portion of) the legacy application. In essence, the knowledge that was “trapped” in the legacy application has been extracted and represented in a model that can be manipulated to demonstrate the proposed changes to the application. The models will also allow for validation that any new development to the legacy application will support the new business need before an organization commits money and time in development.

Once the decision is made to proceed, many tools can generate the artifacts needed to build and test the application. Tools exist today that can generate complete workflow diagrams, simulations/prototypes, requirements, activity diagrams, documentation, and a complete set of well-formed tests automatically from the information gathered above.

Legacy Applications: Will They Become a Thing of the Past?

Current trends toward new software delivery models also show promise in alleviating many of the current problems with legacy applications. Traditional software delivery models require customers to purchase perpetual licenses and host the software in-house. Upgrades were significant events with expensive logistics required to “certify” new releases, to upgrade all user installations, to convert datasets to the new version, and to train users on all the new and changed features. As a result, upgrades did not happen very often, maybe once a year at most.

Software delivery models are evolving, however. Popular in some markets, like customer relationship management (CRM), Software as a Service (SaaS) allows users to subscribe to a service that is delivered online. The customer does not deal with issues of certification, installation and data conversion. In this model, the provider upgrades the application almost on a continual basis, often without the users even realizing it. The application seemingly just evolves in sync with the business and, hopefully, the issue of legacy applications will become a curious chapter in the history of computing. 

Tony Higgins is Vice-President of products at Blueprint. He can be reached at [email protected].

Can I have My Requirements and Test Them Too?

Written by Cynthia Low on . Posted in Articles.

A study by James Martin, An Information Systems Manifesto (ISBN 0134647696) has concluded that 56% of all errors are introduced in the requirements phase and are attributed primarily to poorly written, ambiguous, unclear or missed requirements  Requirements-Based Testing (RBT) addresses this issue by validating requirements to clear any ambiguity or identifying gaps. Essentially, under this methodology you initiate test case development before any design or implementation begins.

Requirements-based testing is not a new concept in software engineering – in fact you may know it as requirements driven testing or some other term entirely – and has been indoctrinated in several software engineering methodologies and quality management frameworks.  In its basic form, it means to start testing activities early in the life cycle beginning with the requirements and design phase and then integrating them all the way through implementation. The process to combine business users, domain experts, requirements authors and testers; and obtain commitments on validated requirements forms the baseline for all development activities. 

The reviewing of test cases by requirements authors and, in some cases, by end users, ensures that you are not only building the right systems (validation) but also building the systems right (verification).  As the development process moves along the software development life cycle, the testing activities are then integrated in the design phase. Since the test case restates the requirements in terms of cause and effect, it can be used to validate the design and its capability to meet the requirements. This means any change in requirements, design or test cases must be carefully integrated in the software life cycle.

So what does this mean in terms of your own software development lifecycle or the overarching methodology? Does it mean that you have to throw out your Software Development Life Cycle (SDLC) process and adopt RBT? The answer is no!. RBT is not an SDLC methodology but simply a best practice that can be embedded in any methodology. Whether the requirements are captured as use cases, as in Unified Process, or scenarios/user stories, as in Agile development models, the practice of integrating requirements with testing early on helps in creating requirement artifacts that are clear, unambiguous and testable. This not only benefits the testing organization but the entire project team. However, the implementation of RBT is much cleaner in formal waterfall-based or waterfall derived approaches and can be more challenging in less formal ones such as Agile or Iterative-based models. Even in the most extreme of the Agile approaches, such as XP, constant validation of requirements is mandated in the form of ‘customer’ or ‘voice of the customer’ sitting side-by-side with the developers.

To illustrate this, let us take the case of an iterative development approach where the requirements are sliced and prioritized for implementation in multiple iterations. The high-risk requirements, such as non-functional or architectural requirements, are typically slated in initial iterations.  Iterations are like sub-projects within the context of a complete software development project. In order to obtain validated test cases, the team consisting of requirements authors, domain experts and testers cycle through the following three sets of activities.

  • Validate business objectives, perform ambiguity analysis. Requirement-test case mapping.
  • Define and formalize requirements and test cases.
  • Review of test cases by requirements authors and domain experts.
canihave1.png

 

Any feedback or changes are quickly incorporated and requirements are corrected. This process is followed until all requirements and test cases are fully validated.

Simply incorporating core RBT principles into your methodology does not imply that fewer errors will be introduced in the requirements phase. What it will do is catch more errors early on in the development process. You have to supplement any RBT exercise by ensuring you have the means to build integrated and version-controlled requirements and test management repositories. You must also have capabilities to detect, automate and report changes to highly interdependent engineering artifacts.  This means proper configuration and change management practices to facilitate timely sharing of this information across teams. For example, if the design changes, the impact of this change must be notified to both the requirements authors and the test teams so that appropriate artifacts are changed and re-validated.

Automating key aspects of RBT also provides the foundation for mining metrics around code and requirements coverage, and can be a leading indicator of the quality of your requirements and test cases. True benefit from the RBT requires a certain level of organizational maturity and automation. The business benefits from having increased software quality and predictable project delivery timelines.  Thus, by integrating testing with your requirements and design activities, you can reduce your overall development time and greatly reduce project risk.

Sammy Wahab is an ALM and Process consultant at MKS Inc. helping clients evaluate, automate and optimize application delivery using MKS Integrity. Mr. Wahab has helped organizations with SDLC and ITSM processes and methodologies supporting quality frameworks such as CMMI and ITIL. He has presented Software Process Automation at several industry events including Microsoft Tech-Ed, Java One, PMI, CA-World, SPIN, CIPS, SSTC (DoD). Mr. Wahab has spent over 20 years in technical, consulting and management roles from software developer to Chief Technology Officer with companies including Tenrox, Osellus, American Express, Parsons, Isopia Compro and Iciniti. Mr. Wahab holds a Masters in Business Administration from the University of Western Ontario.

How to Complete a Software Development Project on Time, on Budget

Written by Cynthia Low on . Posted in Articles.

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework, and as a result, over 80 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality.

It’s a software development business analyst’s nightmare – that doesn’t seem to end.

The potential for error is further heightened because, unlike mechanical or civil engineering where the results of your efforts are tangible, the product of software development is largely conceptual.  When a manager is directing a complex project with several teams, the potential for mistakes or misdirection is especially magnified. Unlike a bridge being built from two sides of a river, significant discrepancies can creep in without an obvious reality check.

To avoid costly errors and delays, business analysts should consider seven key steps in tackling software development projects.

  1. To manage software projects effectively, business analysts need to have an explicit definition of the project’s scope. A clear demarcation of what is in and what is out, what is essential and what is would be nice to have, and what needs to be delivered at the end of the process. All major stakeholders and team members need to have a common understanding of the project goal. Ambiguities at this step can lead to major problems later that can only be resolved by a significant waste of time and money through rework.
  2. Develop concepts into clear requirements. Once stakeholders agree on a common goal, they need to refine their understanding into precise requirements, understandable to all. While it is common for requirements to evolve, starting from a specific requirements baseline provides a foundation to ensure the development process doesn’t drift. By ensuring that stakeholders are deeply involved in defining requirements, business analysts have a solid, universal understanding of the project’s path and scope.
  3. If the project is complex, use models that can be updated as the project evolves. Models represent the product in varying levels of detail and from various perspectives.  Sometimes, there is resistance to building models due to the effort required to maintain them, as new and different elements are incorporated. It is precisely because software development is so complicated that models are needed. With so many conceptual layers being tied together, it can be difficult to keep track of each and every element and their interrelationships. You wouldn’t consider building a bridge without a model. Why would you consider developing software, which is every bit as complicated, without one?
  4. Manage expectations through the project. As software development proceeds, stakeholders often suggest that more functionality be added to the project beyond its original intent. It’s necessary to rely on more than the legal contract to keep projects focused. As more people become involved in the project, regular get-togethers become even more important to ensure that all stakeholders stay aligned.  
  5. Keep the model up to date. Feedback loops are an essential part of most successful projects, and software development is no different. While it might seem time-consuming, keeping the model current provides a touchstone for all stakeholders as the project progresses. It helps maintain focus and exposes when any aspect of the development drifts from its original, or modified, intent. As much as possible, design the model so that it can be updated automatically.
  6. Decompose the model. The model should be designed in such a way that its constituent parts align with work tasks of the team.  In this way, the model parts can be delegated to individual teams to develop or maintain, and later reassembled as needed, to ensure overall integrity at regular milestones.  The process should be managed so that teams, including subcontractors, can come back to the model every so often for a reality check. By so doing, the business analyst keeps the potential for significant rework or outright failure at a minimum.
  7. The process should be built so that all aspects of the model, including those that have progressed, are pulled together regularly to ensure that everything still fits and that modules under development are still proceeding toward the ultimate goal.

But Won’t it Cost More?

Using a management structure that relies on a series of reality checks requires a project budget that allocates time and money for periodic review. The result, however, is that this marginal investment yields far more payback in terms of reduced rework.   An accurate and representative model is a catalyst for more valuable and more frequent feedback. Feedback loops are designed precisely to reduce risk and are found in nearly all engineering disciplines.

With software development projects spending on average 40 percent of their effort on rework, it is worthwhile to use an effective model to ensure your project achieves success.

Consider the alternative: A project that the client rejects, one that has to be reworked hastily, held together by shunts and duct tape. Not only are project funds wasted unnecessarily, but the delivered product’s quality suffers.   Status quo is the expensive path.

Tony Higgins is Vice-President of products at Blueprint Systems. He can be reached at [email protected].

Designing Great Leadership Development Workshops

Written by Cynthia Low on . Posted in Articles.

Ten Core Design Principles

Leadership development workshops are very expensive. And I’m not just referring to the cost of facilities, materials, trainers, and bagels. When a company takes 20 or so managers out of the organization for several days, it is making a significant investment in their development. Those of us who are the architects of these workshops need to ask ourselves the question: Have we designed a workshop that is worthy of this investment? We at Bluepoint have been delivering leadership workshops for over twenty years and have learned that there are 10 core design principles that lead to a great learning experience. I would like to share these with you.

1) Research-based Content

A colleague of ours once mused that many leadership workshops appear to have been created by two guys in a bar in Milwaukee and recorded on the back of a beer coaster. The truth is that anyone can cobble together some interesting exercises and experiences, but to what end? We know the outcomes of great organization leadership…alignment, engagement, retention, productivity, teamwork, agility, to name a few. There is little mystery here. What many designers ignore is all the research that tells us what specific leadership behaviors, practices and approaches will create these outcomes. A good leadership workshop is grounded in this research and, as such, will equip participants with the capability to make an immediate, positive impact on their organizations.

2) Engagement

The frenzied pace that most managers face today has turned the otherwise calm and thoughtful participant into a skittish, distracted bystander, infected by a self-imposed form of ADD with one eye on his or her Blackberry and the other eye on the door. It’s not that these managers are disinterested in their professional development; they are simply products of today’s frenetic organizations. To get their attention, they must be entertained. While describing a good leadership workshop as entertaining may sound like a call to design a boondoggle, unless the workshop can successfully compete with the myriad of distractions facing today’s manager, we will simply be hosting adult day-care. The famous communications guru, Marshall McLuhan, made the connection even more direct with this statement: “It’s misleading to suppose there’s any basic difference between education and entertainment.” Videos, stories, games, debates, physical experiences and colorful materials all play an important role in participant engagement.

3) Story-telling

Every participant comes to the workshop with their own unique leadership story that has grown out of their experiences, beliefs, fears, biases and aspirations. A great workshop challenges the participant to create a bigger story for him or herself and the people that they lead. This can only happen when the participant has the opportunity to tell his or her current story and have it honored in the classroom. Once this happens, a new story can be crafted. The greater the story, the greater the development.

4) Feedback

No workshop ingredient is more potent than feedback. Whether it be multi-rater assessments or direct one-on-one communication, feedback is a powerful stimulus for personal change. And that’s what leadership development really is…personal change. What limits the use of feedback in leadership workshops? I believe it is largely our own arrogance. Too often we feel that the participant cannot handle the feedback. They are too fragile. They will somehow be irreparably damaged by our words or those of fellow participants. Or it may be our own insecurities. We will lose control of the workshop. Emotions will run rampant. We will not be able to handle the resulting carnage. Remember, the workshop is not about you; it’s about the participant. Be bold in creating a feedback-rich environment. The participants will thank you for the gift, maybe not now, but someday.

5) Appreciation

The problem with many leadership development workshops is that there is an underlying assumption that the ideal leader needs to develop a predetermined set of corporate competencies while becoming some fantastic amalgamation of Mother Teresa, Martin Luther King, Gandhi and Jack Welch. Let’s leave that idea to the boys at the bar in Milwaukee. We do not discard these elements entirely from the design process. Corporate culture and strategy rightly have a bearing on workshop design, and there is also much we can learn from the great leaders of the past. However, the best workshops are based on the assumption that all participants come uniquely gifted for the challenge of leadership, and the role of the workshop is to help them identify and cultivate these gifts. It is not our job to help them become the next Steve Jobs, but rather someone much more potent…the best leadership version of themselves. A workshop that is designed to help the participants accelerate the development of their natural strengths is much more potent than one designed to fix the participant or change him or her into the model corporate leader.

6) Intense Experiences

I have asked thousands of workshop participants to reflect on the following five items and select the one that had the most influence on their development as a leader.

(i) Reading and Research
(ii) Performance Appraisals
(iii) Coaching and Mentoring
(iv) Challenging Experiences
(v) Formal Training

Challenging Experiences” was selected by over 90 % of the respondents. (It’s interesting to note that Performance Appraisals always comes in dead last, but that’s a topic for another day.) Even though most designers are keenly aware of these findings, there is a great temptation to fill the workshop agenda with content that is largely extraneous such as succession planning models, managerial competencies, and corporate values. While the intention to provide material that can be applied back on the job is laudable, this information is largely ignored. People can read. Give them the content beforehand. Use the workshop as a learning laboratory where the participants are confronted with real leadership situations. Challenge them to lead at higher levels. Create a curriculum that exposes participants to intense experiences, and allow them to experiment with new behaviors and approaches. This will accelerate their learning and development. (By the way, most savvy managers have read all the corporate tenets and many of the important books on leadership anyway.)

7) Peer Coaching

In my ongoing survey, Coaching and Mentoring always comes in second. One-on-one learning processes are very powerful because, for a period of time, it really is all about me. Because coaching requires no content knowledge, any participant can coach another with a little guidance. For those of us who make our living standing in the front of a classroom trying to be insightful, witty and sage-like, it is difficult to accept the fact that the average peer coaching session is much more effective than our most brilliant lecture. Whenever possible, get your body and ego out of the way and let the participants talk to each other.

8) Self-awareness

It has been said that leadership development is an inside-out game. I like the way Manfred Kets De Vries puts it: “Healthy leaders are passionate…They are very talented in self-observation and self-analysis; the best leaders are highly motivated to spend time in self-reflection.” (Harvard Business Review, January, 2003) The leadership development workshop provides the perfect opportunity for the leader to step out of his or her chaotic schedule, put it in neutral, and take a long, fresh look inward. After all, the only thing participants can work on to improve their leadership is themselves. Put sufficient white space into the workshop design so the participant can personalize the learning. Most managers cannot remember the last time they took 15 minutes in complete silence to contemplate their own leadership journey. Give them the 15 minutes.

9) Performance Breakthroughs

The most frequently voiced dissatisfaction with leadership workshops is the lack of application on the job. It’s not because workshop participants do not want to change; it’s just that real change is so difficult. The pressures of the job, lack of support from their manager, no time…the list goes on. Significant improvement in leadership effectiveness rarely occurs in one big leap. We don’t see the freshly-trained leader walking through the hallways wearing saffron-colored robes, musing about shared community values and throwing rose petals on others (metaphorically speaking, that is). Change occurs incrementally and is fueled by short-term successes – a process that needs to start in the classroom. Bar the classroom door and let no one leave until they have demonstrated at least ten performance breakthroughs (again, metaphorically speaking…I think). Real change starts in the workshop, not back in the office. Start the habit of experimentation and incremental change in the workshop.

10) Learning Accountability

I kick-off many of my leadership coaching assignments with the eternally irritating question: “So, Sally, if nothing changes in your performance what is likely to happen?” Besides the mischievous delight I take in tormenting my clients, I have learned that I can serve them best by insisting that they take full responsibility for their actions, decisions, learning and future. Unless they take personal accountability for their development, there will always be someone else to blame…their board, their staff, their customer, their mother. So too with a leadership workshop. The question that needs to be oft asked at the workshop is “So, George, what have you learned about yourself and what are you going to do about it?

Our clients often report that the two or three days spent in our leadership development workshops were some of the most important days of their careers. Is this because we have great facilitators? Most certainly. A great facilitator can turn almost any curriculum into an important learning experience. But it is also because we try to adhere to the above design principles which, in essence, tell us that the workshop is not about us…it’s about the participant.

Gregg Thompson is a principle of Bluepoint Leadership Development (Canada) and the author of Unleashed! Expecting Greatness and Other Secrets of Coaching for Exceptional Performance. He can be reached at [email protected] or 604-313-5357.