Tag: Skills

As If – Four Steps For Getting and Using Feedback

Written by Kupe Kupersmith on October 7, 2015. Posted in Articles. 2 Comments on As If – Four Steps For Getting and Using Feedback

Join us in New York October 13-15 at Project Summit *Business Analyst World where Kupe is a keynote speaker. Spaces still available! Don’t miss your chance to see this amazing presentation – Register Today!

As if you thought it was impossible to associate the complexity of business analysis with the simplicity of Clueless, I’ve done it!

No matter who you are, what you know or what you can do for your company, knowing how to request and manage feedback is one of the most important skills you will need in order to continue to grow and improve. Using this “AS IF” technique, I’ll guide you through the four steps for requesting, receiving, implementing and following up on feedback.

I’m going to talk about a four part system that will help you get the feedback you need.

Ask for feedback
Say “thank you.”
Implement the feedback
Feedback on the Feedback

The first step is asking for feedback. Nine out of ten people don’t give you the feedback you need in order to improve, so you have to ask them: what you did well, what you didn’t do so well, and where you can improve. It’s not natural for people just to throw out advice that you need, so make sure you ask. Start with people you trust, people you know, people that have your best interest at heart.

Step two is just say “thank you.” Don’t get all defensive. Feedback is a personal attack…or it feels like that. So it’s gonna hurt. But don’t come up with excuse after excuse of why you did something. Just say “thank you.” Then go off in the corner, if you have to, and start to cry. (But don’t do it in front of the person that gave you the feedback.) You know the old saying, “no pain, no gain.” Feedback is a little painful but you need it to really move forward and improve.

Okay. So now that you’ve recovered from the pain, the third step in the process is implementing the feedback. Sit back and really think about what you can do with the advice that person gave you. How are you going to implement this? What are you going to do differently? How are you going to change your behaviors? How are you going to improve?

The fourth step is to give feedback on the feedback. Go back to the person and say “Thank you again for that feedback! Here’s what I’m doing: I’m going to do one, two, and three differently going forward…”

By getting your feedback on the feedback, the person realizes that not only did you take the time to listen to them, you took time to think about how you’re going to implement and actually change. And the next time you go to that person they’re more apt to give you the feedback you need.

Now there’s a caveat with number three. What if you sit back and think about it, take that advice, and try to figure out how you’re going to implement it, and it doesn’t feel right?

You know yourself the best, so it’s okay not to implement the feedback. You can decide, “You know what? That’s not who I am, and that’s not where I want to go.”

Now you still need to give feedback on the feedback. Go back to the person and say, “I listened to you. I thought about it, but it’s not right for me. The advice you gave doesn’t fit with where I want to go.”

So it’s okay not to implement the feedback. Just give feedback on it. The reason you still do step four, feedback on the feedback, is that you don’t want people to see you in a similar situation doing the same thing after they took the time to give you advice. You didn’t do anything with it, so why would they give you any advice in the future? Does that make sense?

Okay so here’s a little example from my real world.

I do a lot of keynote presentations, and I’m always asking people to give me feedback. Somebody told me once, “Kupe, you say ‘gotta,’ ‘gonna’ and other kind of slang words here and there, and you really have to take that out of your speech.”

I said “Thank you,” and I thought about it, and I realized that in my approach to speaking, I want to be me. I want to be flexible up there…transparent. I want to be who I am. If I had to think about every single word I said, then I would get more robotic and it wouldn’t be me. So I decided not to implement that feedback.

I went back to the person and said “Hey, I’ve gotta tell you something,”

(And hopefully by now you got the joke…I gotta tell you something). “I’m not gonna implement your feedback, and here’s why…”

Does that make sense? That way the next time they saw me speak, and they heard me say “gotta” and “gonna,” they wouldn’t be upset. They would get it.

So I hope this is helpful. Please share with all your friends and your team, and start to improve. You’re awesome, and here’s to your improvement!

Now, it’s your turn – ask a co-worker, your boss or a friend (yes, this can be used in your personal life too) something about a recent project, task or situation to start implementing your own feedback system today. From there, keep asking questions and don’t forget to close the circle and give feedback on the feedback! For a few more tips on some subtle aspects of feedback that are important to keep in mind, take a look at our Instructor and Agile Practice Lead, Kent’s, new The Power of Feedback blog post.

Speaking of feedback…we know your inbox is full and we don’t want to create content just to have something to send you. Let us know what we can provide to help you the most: 3 Quick Questions. Thank you.

And be sure to let me know your thoughts on feedback below!

All the best,

– Kupe

*reprinted with permission from the author

Nine Key Skills That Every Good Business Analyst Needs

Written by Abbie Cockburn on July 22, 2015. Posted in Articles.

Being a successful Business Analyst means you have to have a variety of different skills and be adaptable to a changing environment. Every Business Analyst will bring their unique blend of skills and experience to the role, of course, but I’ve highlighted below what I think are the most common skills that a good BA will need. Feel free to add in the comments any other skills that you have found helpful in your BA career.

1. Understand your objectives.

Being able to interpret direction is important. If you don’t fully understand what and, more importantly, why you are being asked to do something, there is a risk that you won’t deliver what’s required. Don’t be worried about asking for further information if your brief isn’t clear.

2. Good verbal communication skills.

It is essential that you are a good communicator, regardless of the method of communication. You must be able to make your point clearly and unambiguously. It is also important that you know how to ask insightful questions to retrieve the information you need from stakeholders. For example, if your stakeholder isn’t a technical specialist you may need to ask your questions in plain English – avoiding jargon and acronyms. Being able to communicate information at the appropriate level is vital – some stakeholders will need more detailed information than others.

3. The ability to run stakeholder meetings.

Although using email provides a useful audit trail, sometimes it is not enough to communicate with stakeholders via email. Don’t underestimate the value of face to face meetings to discuss problems in more detail and clear up any queries. Often you will discover more about your project from a face to face meeting where people tend to be more open about discussing situations. You can always follow up a meeting with written confirmation if an audit trail is required.

4. Be a good listener.

Listening skills are key to being a successful BA. You must be able to listen and absorb information. This will allow you to analyse thoroughly the information gathered to specify requirements. It’s important that you don’t just listen to what’s being said, but are able to understand the context of what’s being said – the motivation behind it, the circumstances behind what’s being said, and even what’s not being said. Voice tone and body language can help you understand the message behind the words.

5. Hone your presentation skills.

It is likely that at some point in your career as a BA you will need to facilitate a workshop, or present a piece of work to a stakeholder or project team. Consider the content of your presentation and make sure it matches the objectives of the meeting – there is no point in presenting information about implementation methods if the meeting is being held to discuss requirements gathering. These presentations are not only for you to present information. They can also work as an excellent way to extract more information or clarity from stakeholders if you are unclear on something or are looking for more detail on a particular area of the project.

6. Be excellent at time management.

A BA must have excellent time management skills to ensure that work is completed on time and the project does not fall behind schedule. Multi-tasking is an important skill, but you must also be able to prioritise activities – understanding which are more critical than others – and concentrate on them. Remember that you need to manage your own time and activities, but you may also need to manage other people’s time if you are dependent on them for information. Make sure that they know when you need them to deliver.

7. Documentation and writing skills.

Requirements documents, reports, specifications, plans and analysis. As a BA you will be required to deliver a range of different types of documents. You will need to ensure that your documents are written in a clear and concise manner, and at a level that is appropriate for your stakeholders. Avoid nuances specific to a particular workstream as they may not be understood by all stakeholders. As an inexperienced/beginner BA, it is unlikely that you will have experience writing requirements documentation, however, strong writing skills are an excellent starting point. Experience will lead to clear and concise requirements documentation.

8. Stakeholder management.

It is essential that you know how to manage all of you stakeholders and know how much power and influence they have on your project. Stakeholders can be your strongest supporters or your biggest critics. An experienced BA will be able to analyse how much management each stakeholder needs and how they should be individually managed. Do they need face to face meetings and detailed information or are they content with high-level reports? Are they supportive of your project? Knowing the answers to these key questions will help you to manage your stakeholders and the wider project. Can you influence them directly or do you need to influence someone who can influence them.

9. Develop your modelling skills.

As the saying goes a picture paints a thousand words. Techniques such as process modelling are effective tools to convey large amounts of information without relying on text. A visual representation allows you to get an overview of the problem or project so that you can see what works well and where the gaps lie. A typical process model will have several different levels of detail to allow a BA to engage with stakeholders in a language that they understand.

Don’t forget to leave your comments below.

Even Business Analysts Need Love

Written by Marcos Ferrer on June 29, 2015. Posted in Articles.

Attention all stakeholders of the solar federation. My personal life has recently tuned me into pain in a way that makes me realize that the BA’s professional life offers great pain. “NO!”, you say, yet here is a list of hurts you may well have inflicted on a BA if you think about it carefully.

Don’t do these things:

Don’t kick the BA off the project just because they made a deliverable that looks like requirements to you even though you didn’t read it (sponsor, sponsor, sponsor). Your (anyone’s) deadline allows only the beginning of organizational learning. The loss of the BA guarantees the end of learning, never mind the teaching that must follow for change management success.

Don’t hire a BA if you know better than they do. You will annoy yourself while amusing the BA, which will only annoy you more.

Don’t give requirements as if they were dictation. If a BA takes your requirements EXACTLY as you give them and does not present an “analyzed” model showing what the requirements might REALLY be, it might even be that your BA does not like you.

Don’t dislike the BA. At worst they are only messengers, and at best they can get you results that you actually want.

Don’t withhold pay. Because may BA assignments are “temporary” (see above), many BAs are consultants/contractors/temporary. Making them wait long periods to be paid is not good for them, you OR them.

Don’t keep the BA in the dark. They can see how silly you look in the dark

Don’t yell at, or curse at the BA. Yeah, really. You know who you are, and so does everybody else on the project. Recriminations are not requirements. Not.

Don’t not read the requirements.

Don’t not read the email. Yes, it is OK for an email to have more than one sentence.

Don’t gush over the diagram just because it is nice. Be specific in your gushing, as in “I really like the fact that I can see ALL the redundancies across payment types” or “The pink really highlights just how risky a full cutover is, and how it pays to set up three teams.”

Don’t be impressed with nice looking diagrams unless the content is robust. The cuter the graphics, the less likely the analyst spent time on re-factoring process, the more likely the analyst spent time on re-factoring the format.

Don’t bring everyone to every meeting. The amount of work progress made in a meeting is inversely proportional to the square of the number of people. Eight people will accomplish 1/16 of the work that 2 might. Enforce the rule by accomplishing actual work at every meeting. This will help you keep meetings small.

Don’t accuse the BA of “blowing your scope”. It isn’t your scope, it belongs to the business. Besides, you got the scope wrong in the first place by rushing to solution, then broke everyone’s spirit by preventing any improvement once the team understood what the scope actually meant.

Don’t rush to solution. Plan the different approaches, from simple/cheap to complex/low chance of success. Use each simple approach to advance the solution by REALLY learning from it. REALLY.

Don’t have the BA walked out the door immediately, even when you must let them go. They don’t have access to sensitive systems functions (are they sysadmins or BAs?) and if what they know is dangerous to you walking them out is no way to make friends, and you are going to need friends (see 1st item above).

Don’t ignore maintenance of the highest level descriptions just because “everyone knows that”. If you are engaged in enterprise systems transformations, everyone is going to go from 5 people to 10 people to 40 people over a couple of years, and then to 20,000 overnight. Be ready for everyone – there will ALWAYS be new people, and a failure to model the highest levels of business requirements and process is the number one cause of failure – the big mistakes happen at the top levels of description.

Don’t insist that BAs produce meeting minutes – better they should produce models that represent business thoughts and decisions so stakeholders can see what they said. The alternative is to build based on the say as seen in the minutes. Then you will hear stakeholders say “I can’t say I see what this does for me.”

DO learn along with your BA, who is learning your needs and combining them with others that you don’t have time to learn. So many voices channeled through one, neutral, zero attitude model for all to reflect upon. Bliss, you think?

Don’t forget to tell me what you think, since you read this far, your opinion is already 1st percentile. Comments below 🙂

Don’t forget to leave your comments below.

Business Analyst Skills – Overview

Written by Mani Ramasarma on April 20, 2015. Posted in Articles.

In my previous post I promised to list the skills a Business Analyst must have. While there are many qualities/skills required I list only those that are critical. After all, there is no “ideal” BA!! Before I do that let me briefly discuss the types of BA’s as the skills differ slightly for each.

BA’s can be classified into 4 types – Operational, Project, Enterprise, and Strategic. An operational BA is responsible for one or more systems that are currently in use. This person analyzes issues, prioritizes them with business users, coordinates with the technical team and ensures the issue is fixed. The original BRD/FS is appropriately updated. A project BA, as the name suggests, is part of the project team to build or implement a new system. An enterprise BA has a cross-functional view of the organization. A “go-to” person when the project cuts across multiple business units or functions. A strategic BA is more of an advisor/consultant interacting with the business constantly and guiding them in making long-term decisions related to business processes or systems. What skills must a BA in general possess?

Google for BA skills and you will find plenty of them – “4 key skill sets for a seasoned BA”, “8 BA skills for success”, “The Top ten skill sets for a BA” and so on. I listed some of the skills in my previous blog, which I repeat here in greater detail. A few more skills are also added to the list. Again, these are based on my past experience and are common to most situations. Additional skills will be required for different situations.

Active listening. It is a communication technique used in counseling, training and conflict resolution, which requires the listener to feed back what they hear to the speaker, by way of re-stating or paraphrasing what they have heard in their own words, to confirm what they have heard and moreover, to confirm the understanding of both parties . Communication is incomplete if the listener does not comprehend what is being said. Re-stating and paraphrasing is an effective way to understand what the other person is saying. While doing so do not miss out on important facts. Watch for body language too. It provides clues to the importance of the requirement as well as UI design. For example, while discussing a requirement the users may gesture a drop down or a click without verbally stating it. Note them down.
Patience. It’s a virtue that all BA’s must have. First, not everyone has clarity of thought. Second, business users do their job really well but may not be articulate enough. Third, they may not have the patience to sit and explain fundamental things to you. It’s like being in a relationship. Two impatient people make the situation quite explosive. This attribute is something to be cultivated. If you have not read Dale Carnegie’s book “How to Win Friends and Influence People” please do so. There are many examples in there that show how patience can get what you want.
Persistence. You have to strike the right balance. Extreme persistence will annoy people. Extreme non-persistence will result in inadequate requirements. Walk the thin line. Persevere until you get the information required without annoying the business users. Patience and humor are important tools here. Yet another approach is to understand the mental makeup, idiosyncrasies, likes and dislikes, interest, hobbies of the person you will be dealing with. How to get this information? Have an informal chat, coffee, lunch with the person/s before setting off on the formal process of requirements elicitation. Here is a cue from Dale Carnegie – people love to talk about their experience. Once you establish a personal connection, not much of effort is required on the persistence front. Remember, nothing comes easy.
Documentation. Translating requirements as communicated by the users and as understood by you into a BRD/FS requires a good command over written English. Ability to document in a lucid way without diluting the essence of the user needs is a necessity every BA must possess. Supporting user needs with examples in a clear, concise manner ensures the business users and the technical team understand the requirements in a consistent fashion. The key word here is “consistent”. Business users and the technical team must comprehend it the same way. Writing need not be Shakespearean. Simple, grammatically correct sentences are good enough. Where do you start?
1. Review some of the existing documents. Do they appeal to you? Do they grab your attention? How would you revise it to make it more appealing? Are they clear? If not, what is missing? Remember to try to add those missing ingredients to your documents.
2. Rewrite some of the documents, if not the whole, at least the portion that is dowdy.
3. Do not use words where the reader has to refer a dictionary (dowdy is a good example, it means dull, unattractive).
4. Peer review is yet another way to improve your documentation skills. Some people are very good with punctuation (my weak point). Some are good with word choice and some are good with spelling (my strong point). (I had this document peer-reviewed too).
5. Use Microsoft Word’s built-in, rudimentary spell check and grammar check. You can ward off some of the basic problems.
6. Some of the fundamental writing mistakes to avoid – mixing up tenses, switching between first, second and third persons, verb-number disagreement.
7. Write in active tone.
  Keep in mind that a poorly worded document is rarely read to completion. Also keep in mind that a BRD or FS will be a live document as long as the system exists. So, get the documentation right.
Analytical skills. The bread and butter of a BA. Ability to dissect a requirement, understand its need, study its impact on upstream and downstream systems, and comprehend its role in the grand scheme of things (seeing the forest AND the trees) is absolutely essential. This website lists areas where analytical skills are required and is not restricted to BA’s. I have seen some amazing young BA’s with excellent analytical skills too as well as some experienced ones with waning analytical abilities. How to improve analytical skills? (the assumption here is you already have a level of analytical skills) There are many tools to help you, like Fishbone diagram, 5-why methodology, and much more. Playing Sudoku (not during office hours) helps a great deal in improving analytical abilities. How much to analyze? Enough to implement the requirement and avoid analysis-paralysis. Here are some points to bear in mind:
1. Always keep the objective in mind.
2. Establish a time limit to conclude your analysis process.
3. Perfection is not the criteria, adequacy is.
4. Check with a senior colleague.
5. Go with your gut feel.
Conflict management. Conflict is common place in the life of a BA, while gathering requirements, analyzing, communicating to technical team, and testing. Some of the skills mentioned in my earlier blog will definitely help manage these conflicts. Eliyahu Goldratt in his book Theory of Constraints (TOC) provides a methodical way of resolving conflicts. He calls it the “evaporating cloud” . It is a logical and graphical way to resolving conflicts. The diagram must be viewed from right to left (like Arabic). Yet another method is to follow the 2-minute rule. If a resolution is not found within 2 minutes, keep it aside and table it later. Never get into an argument. You may win it but you will lose the goodwill of the person.
Be aware of the escalation process too. Do not escalate at the drop of a hat. Tact is absolutely essential so as not to mess up the relationship with the business.
Communication. Here is a high-level list of things to do:
1. Have an agenda for each meeting and share it before hand.
2. Follow up each meeting with a written communication of what was discussed and provide readers with a timeframe by when they should confirm.
3. Keep the communication channel with the business users open. There is a general tendency to switch it off once requirements are gathered till UAT. In the interim keep the users updated of the progress being made.
4. Have walk-through sessions with the technical team to explain the requirements.
5. Document all explanations and clarifications provided. This will help avoid a ‘you-said-she-said’ situation.
6. Communication must be clear, concise and correct. Use bullets instead of paragraphs where possible.
7. If you are not sure how your message will be understood, save the communication as draft. Revisit it a day or two later and if it still sounds good send it.
8. Spell check and grammar check before sending out the communication. When in doubt, ask someone else to read it.

The list is by no means complete. Different situations demand diverse skills. Some can be acquired while others come through experience. In my next blog I will discuss the techniques available to a BA for eliciting requirements but before that let me acquire some more of the below skills myself !!!

Don’t forget to leave your comments below.

A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by Robert K. Wysocki on August 11, 2014. Posted in Articles.

It is widely accepted that the elicitation of complete requirements during project ideation is very unlikely except in the simplest of projects. There are a number of internal and external factors that affect the solution and its clarity that often change during the project life span that accounts for this. The environment is dynamic. It doesn’t stand still just because you are managing a project! These factors create process challenges that can be mitigated by a simple change in the definition we use for a requirement. This simple change of definition simplifies many of the project management process problems and improves the likelihood of delivering the expected business value.

THE REALITIES OF THE COMPLEX PROJECT LANDSCAPE

As part of the Ideation Phase of a complex project we can define
“WHAT” an acceptable solution has to contain and the business
value it is expected to generate.

At the start of a complex project we may “NOT KNOW HOW” to
achieve an acceptable solution.

The resulting incompleteness is a logical consequence of the
Plan-driven definition of a requirement. That incompleteness can
be removed by using a Change-driven definition of a requirement.

Using a Change-driven definition of requirements implies that an
iterative project management approach will be required.

Most project management processes use a Plan-driven definition of requirements. That will not work in the contemporary complex project landscape. This article introduces a Change-driven definition of requirements. That simple change eliminates the obstacle.

A SOLUTION TO INCOMPLETE REQUIREMENTS

To a certain extent we have become trapped by our own view of requirements and their elicitation. The IIBA definition may fulfill its objectives but at what price? The IIBA definition of requirement is a Plan-driven definition and it tries to define both the “what” and the “how”. In independent projects that works. But in complex projects that seldom works. The Effective Complex Project Management (ECPM) definition of requirements proposed below is a Change-driven definition. It focuses only on the “what”. The “how” is developed within the Work Breakdown Structure (WBS) and the project execution phase.

THE ECPM DEFINITION OF REQUIREMENTS

The IIBA definition is all well and good and I’m not going to challenge it. I assume it accomplishes what its creators envisioned. But let me offer a different perspective for your consideration. I believe we execute projects to solve critical problems or exploit untapped business opportunities with the ultimate goal of generating business value.

The need to deliver business value

Using cost, time and scope as the variables for measuring project success misses the point of doing a project. The success of a project is measured by the achievement of business value – the more the better. The total cost of the project is measured against the business value generated to calculate Return on Investment (ROI) and compare against other projects competing for the same resource pool.

Complexity and uncertainty

The IIBA definition of requirements is a one step Plan-driven definition. That gives rise to incomplete requirements except in the simplest of situations. The definition of an ECPM requirement given below is a two step Change-Driven definition. In the first step the requirements definition focuses on the “what”. At this level requirements are complete. Think of them as defining an ideal end state. With requirement defined the focus of the solution turns to the second step – the “how”.

DEFINITION: ECPM Requirement

An ECPM requirement defines a component of the desired
end state and when integrated into the solution meets one
or more business needs and delivers specific, measurable
and incremental business value to the client business unit.

The set of ECPM requirements forms the necessary and
sufficient set needed to establish the desired end state and
attain the planned business value.

Adapted from: Wysocki, Robert K, (September, 2014), “Effective Complex
Project Management: An Adaptive Agile Framework for
Delivering Business Value”, J. Ross Publishers

“How” is usually not known at the outset of the complex project. It can only be discovered through successive learning and discovery iterations that build upon a solution that is converging to the desired end state. So at the start of the complex project the definition of “how” is incomplete. Very little of the solution might be known at the outset or most of the solution known with only a few details missing but the solution is not completely known at the outset. So the “how” is the second step of the ECPM requirements definition and its discovery is imbedded in the Work Breakdown Structure (WBS).

The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the planned business value and none of the requirements are superfluous. This is important because the project was justified based on the expected business value as described through the success criteria in the Project Overview Statement (POS). Linking requirements to the success criteria provides a basis on which to prioritize requirements.

This definition of a requirement is quite different than the IIBA definition but in its simplicity and uniqueness it puts the connection between requirements and the business value in a much more intuitive light. I have no particular issue with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use the ECPM definition throughout this article.

An example of an ECPM Requirement
from a project to establish a
Workforce and Business Development Center

A Business Incubation Center (BIC) (Figure 1) to support the needs of students, workers, entrepreneurs and local businesses for career and professional development and business growth.

Figure 1: The Business Incubation Center (BIC)

Requirements will be the causal factors that drive the attainment of the success criteria as stated in the POS. Every requirement must be directly related to one or more project success criteria stated in the POS. This definition results in a small number (less than 12 for example) of high level requirements at the beginning of the project, whereas the IIBA definition generates hundreds and even thousands of requirements which can never be considered complete at the beginning of the project. The last time I applied the IIBA definition resulted in my client and team generating over 1400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made in that example is highly unlikely. Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM Requirements definition can be considered complete at the beginning of the project. An ECPM Requirement is a more business-value-oriented definition than the IIBA definition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposing them to the function, sub-function, process, activity, and feature levels. The first-level decomposition of a requirement is to the functional level and can be considered equivalent to IIBA requirements but in ECPM parlance it is no longer a requirement. It is a function that must be present as a condition of achieving the requirement. So while you can identify all requirements at the beginning of the project you cannot describe the details of the requirements at the functional, process, activity and feature levels. This detail is learned and discovered in the context of the cycles that make up the project.

BENEFITS FROM USING ECPM REQUIREMENTS

Framed in the language of the client
Relate directly to the generation of business value
Helps create and maintain client ownership and meaningful involvement
Integrates all of the steps that define effective complex project management
Reduces the number of requirements from hundreds to less than 12.
Become the basis for solution development
Related directly to project success criteria

PUTTING IT ALL TOGETHER

Current definitions of requirements include both the “what” and the “how.” This leads to incomplete requirements specification for every project except the simplest. The result is confusion and problems associated with the execution of the chosen complex project management process. The ECPM Requirements definition focuses on the “what” and with few exceptions will be complete. Choosing the best fit complex project management process becomes a well-defined decision. The “how” is identified incrementally through a Work Breakdown Structure (WBS) derived from the set of requirements.

Deploying this ECPM Requirements definition across the project life span introduces changes to the project management process that have every reason to significantly improve project performance and reduce the risk of project failure. The discussion of those changes is beyond the scope of this article.

Don’t forget to leave your comments below.