Skip to main content

Personal Identification: The Soft Skills PRECEDE the Hard Skills, for BAs

Doggone and dadblast it, what is going on! Didn’t I just say the opposite last month? How is your tolerance for ambiguity holding up? Are you on top of the BABOK 1.6 BA Fundamentals? If you are aspiring to the top of your profession, and have the courage to self-identify, dive right in!

I begin by quoting the entirety of BABOK Chapter 8 here (don’t panic, it fits in the blog):

Chapter 8: Underlying Fundamentals
8.1 Introduction

8.2 Basic Skills
8.2.1 Analysis Skills

.1 Structured Analysis Techniques
.2 Issue Management
.3 Communication Skills
.4 Learning Skills
.5 Usability

8.2.2 Business/Domain Knowledge
.1 Products
.2 Processes
.3 Markets
.4 Systems
.5 Sources of Knowledge

8.2.3 IT Knowledge
.1 Paradigms
.2 Methodologies

8.3 Advanced Skills
8.3.1 Meeting Management
8.3.2 Presentation Skills
8.3.3 Decision-making Skills
8.3.4 Facilitation Skills
8.3.5 Communication Skills
8.3.6 Conflict Resolution
8.3.7 Negotiation Skills
8.3.8 Relationship Skills
8.3.9 Questioning Skills
8.3.10 Systems Thinking
8.3.11 Escalation Skills
8.3.12 Logic
8.3.13 Cultural Awareness

8.4 Leadership Skills
8.4.1 Coaching Skills
8.4.2 Facilitating Long-term Goal Setting
8.4.3 Motivational skills
8.4.4 Appraisal Skills
8.4.5 Interviewing Skills
8.4.6 Role Definition
8.4.7 Behavioral Coaching
8.4.8 Delegation skills
8.4.9 Succession Planning
8.4.10 IT Architectural Skills

8.5 Peripheral Skills
8.5.1 Sales

8.6 References

Interestingly enough, it is only the Basic Skills that have any detail at all, and those not much. What does this mean? The Basic Skills are the things that we learn just by doing IT requirements work. So many BAs cut their teeth on IT, that this is “self-evident” to many of us. The KEY skill is that we LEARN.

Self-test number 1:
Did you love school, or at least did you love reading and learning? Can you see the relationship between a three-year IT project and a three-year PhD program? WHY is it important to involve stakeholders (bet you don’t know)?

Next are the Advanced Skills. These are the sorts of things that BAs learn when (typically) we have been in a job long enough to have institutional knowledge and process experience, plus enough maturity to get along. In effect we get “promoted” to working with more people. We may not be good at it at first, but we’re here because we know so much and can share it. This thrusts us beyond analysis of processes affecting teams, into the processes of team analysis. We can lead the team to meetings, but can we make them think?

Self-test number 2:
How balanced were your SAT scores? Are you as comfortable with words as you are with complex IT and financial concepts? Would you rather listen, except when it is vital to talk?

Then comes Leadership Skills. This is Advanced Skills on steroids, in the sense that NOW you can really make it work, not just oversee uninspired meetings and team sessions.

Self-test number 3:
Do people just fall all over themselves to be with you and get your approval and do what you say because you are just plain charismatic and, frankly, too sexy for your project? If not, have you held at least one sales job for more than two years? If not, try it and find out if you want to lead.

Yes, this is the punchline. Leadership IS influence, regardless of style, or outcome. Sales IS the profession of learning to influence, for good or for evil (both kinds of leaders are out there – which will YOU be?).

SO, as you look for “people skills”, don’t forget that a successful sale means a happy customer, whether the customer is a stakeholder, an executive, a system user, a boss, or an IT team member.

Happy customers are getting what they want – good systems; no one loves a salesman who sells a lemon. If you have happy customers, you are on your way to the top of the profession.

Here is the problem we have posed: BUT, loyal reader, I am out of time this month.

© 2008 Marcos Ferrer

Enterprise Requirements Alignment: The Top Three Challenges

1. Change Management as an enterprise core competency. Consider any particular requirement. At any point in time, one of the following is true:

  1. The requirement is valid but not being met – in which case some aspect of the solution must be changed. 
  2. The requirement is not valid (even if it used to be) – subjecting it to further iterations of the requirements life cycle and corresponding changes to the underlying solution 
  3. The requirement is being met and will remain valid for the foreseeable future – in which case attention will turn to changes to the solution for increased efficiencies. (This means, by the way, that even the “as is” operational elements of an enterprise are as subject to change as the transformational elements.

    In other words, if the requirement is not being met, change is necessary. And if the requirement is being met, change is necessary. Earlier posts to this blog have said plenty about the position that everyone in an enterprise is carrying out requirements management within their respective domains. But what is requirements management but a specific form of change management?

2. Financial Fluency as an enterprise core competency. It is easy to construe scenarios in which the failure of even a single small-scope technical component of an IT based business solution can totally eliminate the solution’s business case. That means that senior management’s view of the solution’s status throughout the life cycle would ideally assimilate the status of that component, requiring the component’s owner to be able to express status in senior management terms of cost, risks, and trend. In other words, each contributor to a solution needs to be financially fluent within his or her domain. And, every time a change must be accommodated, contributors to the solution must reflect how that change impacts the financial picture for their own contributions.

3. The Business Analysis Center of Excellence (BACOE). Enterprise-wide consistency in managing changes to requirements and solutions, along with consistency in measuring, monitoring, and status reporting across, up and down the enterprise requirements hierarchy, demands an enterprise-level entity. This would serve to define and drive the implementation and continuous improvement of best practices in change management and financial management.

You might notice that I have not included in the top three the selection of a tool to underpin enterprise-wide change, requirements, and financial management. Tools are easy. The real challenge is driving the enterprise culture to the point where an understanding of one’s job in terms of requirements management, change management, and financial management is second nature.

Terry Longo has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through or at [email protected]

Alignment, Requirements, CBAP and MORE!!

globe_Mar17_150x135.pngGreat line-up of articles and blogs for this issue! From proper language of alignment to CBAP Soup to Nuts and everything in between, including a Letter from the IIBA President in the IIBA Insight section. I know that you’ll really enjoy this issue’s content.

I want to personally thank not only YOU, our subscriber, but all of our content contributors. We truly appreciate your insight, thoughts and overall contribution. Now – I’ve got one request to YOU – let’s here your feedback.

We have had a few suggestions to our new suggestion box, which we have quickly acted upon. Please utilize this new opportunity for you to offer ways to improve the site, suggest content, or offer new discussions forums you think we should add. We can not continue to improve without hearing from you so keep the suggestions flying!

Stay tuned for our 1 year anniversary celebration! Happy reading!

Best Regards,

Adam R. Kahn

The Language of Alignment

Business benefit, growth, and profitability. Cost and risk. Value add. Forecast confidence. Customer satisfaction and loyalty. These are the measures of senior management. And if the goal of a commercial enterprise is to make money now and in the future, everyone in the enterprise needs to be behind that goal.

You manage a business unit and are looking at a red/amber/green dashboard report of your current programs, and you see that one is red. With your browser, you drill down the trail of red, each click bringing you to a lower level dashboard with more detail about a specific aspect of the at-risk program. Here is what you find:

  • The business’s success with a new product line is at risk because
  • The sales teams might not be prepared to sell the new product line because
  • Sales training for the new product line may be delayed because
  • Implementation of the Learning Management System (LMS) may be delayed because
  • The LMS module used for the management of training records may be delayed because
  • Development of the core code library for that module may be delayed because
  • The lead developer may need to leave the project due to an important and urgent personal matter

While the above may seem dreamy, it’s where we’re headed. Everybody in a value supply chain, from the lead developer to the LMS implementation project lead, to the sales team manager, to the business unit manager should, at any point in time, be able to express the status of his or her responsibilities in terms of Cost, Risk and Business Benefit.

The costs, risks, and benefits of what, you may ask? Simply put, for each person or team in the value supply chain, the costs, risks, and benefits of meeting their requirements.

Previously I have argued that the requirements management activities of planning, eliciting, etc. are necessary regardless of the domain in which one is working (instructional design, business strategy, database design, etc.). It is not only possible, but necessary, that requirements managers in those domains be able to express their status in terms of cost, risk, and business benefit. Rolling up requirements status to a senior level necessitates a common language, and that language is defined by the top-level requirement(s) of the enterprise.

We have much to do. In my next post, we will elaborate on the above and identify the top three challenges in achieving the dream.

Do you have any thoughts or questions about this post and earlier posts? Please don’t be shy! Let us know what you’re thinking by adding a comment below.

Terry Longo
has more than 25 years of IT experience, including software development, system and network administration, and instructing, as well as being responsible for the requirements, project management, and delivery aspects of complex training solutions. He currently holds the IT Service Manager ITIL and is responsible for HP Education’s ITIL, Project Management and Business Analysis curriculums in the US. Terry can be reached through

or at [email protected]

Never Let a Good Editor Go

When documenting systems, quality assurance requires quality support people, especially final content editors. They are worth their weight in gold-edged certificates. If you are part of a large project that has a very large documentation aspect, learn to nurture, develop, and retain a good editorial staff, and do not forget to keep everyone’s skills current on the tools you are using! The current crop of word processor and presentation software packages are constantly adding features to make your life easier.

In our ever more technical world, documentation is still one of the most important aspects. Everyone likes to “feel the weight” of what they accomplished, and documentation is commonly a major part of closure in a project.

The Second Eye
If you have ever had to write a program or a document that was 2000 pages or longer, you will probably get to the point of forgetting what you wrote days, weeks, or months ago. I know I do. That is where a good editor can save the day. Make it a habit of passing along the content in reasonably sized pieces to another soul who dutifully reads every line, checks every drawing for accuracy, and checks syntax and examples. This is a truly wonderful thing.

 A second set of eyes will see things that you cannot. Spelling, grammar, syntax, run on sentences, redundancy, too much or too little detail, irrelevant details, your own quirky tidbits that might not be as clear to them as to you, the list is endless … and the work is absolutely crucial!

Praise Your Editor
Thank them for finding those errors that you were unable to see after looking at the same page for hours. Most modern word processors can handle spelling errors but not if they are technical jargon or corporate jargon.

I like to break my content into smaller, specific pieces if possible, but this does depend on the client requirements. If the programs are small, then the sections can be small and succinct. In some cases, the sections require previous sections to be completed and functioning. Only someone who was totally familiar with the whole picture, the end product, and the inter-relationships of the pieces can provide you with a good set of eyes to review your content with.

Send them praises: Excellent work finding “the the”, “good idea to add that as well”, “you are once again correct, that part is unnecessary”. “good eye, I forgot that topic entirely”…

Editing is an Art
Being an editor requires a great depth and breadth of knowledge on the subject. I would not pass this document on to my teenage daughter; it would be gibberish. She once asked me to “fix” her paragraphs about the Crusades. I expounded on them and thought I was keeping it simple. Alas, I was way too technical. I added about 10 extra words for every two of hers. Then there are many times when I edit her words to be, shall we say, more accurate.

On some recent technical documents, I was doing the developing and passing it on to three evil editors. The first two were masochistic, butchering the youngling without regard for effect, it seemed. They passed it to the third editor, a very technical person, who must have thought I was completely incompetent when he got the butchered remains of my work. It was an interesting few months of trying to figure out their system. And, interestingly enough, that last technical editor was actually very competent. He never missed a detail, was very thorough and fortunately knew his stuff. The other two butchers were trying to fit the content into a web page design rather than have the web page provide the content.

Editing Adds Time
It is highly likely that your editor is not doing this full time for you. Hence, you need to allow for their scheduling requirements within your schedule. Having lots of lag time is always nice. Giving them clearly stated times and dates for delivery of their edits are other important aspects. Everything takes time, and time gets consumed faster the closer the project deadline is.

When I line up an editor, I make it clear there is some flexibility in their timelines at the beginning especially and I try to ensure that deadlines do not force me, or them, to cut corners. Deadlines really are annoying at times! I also make it very clear what the deadlines are and how they can help me meet them, along with general ideas of what I want them to look for, and how they should send change requests or make adjustments.

Give Them Source or Don’t Give Them Source?
This can be a tricky issue. Should you give your editor the source and let them make changes directly to the document? Yes and no.

If you can have tracking of changes, this is always an excellent idea. What if they change your source document without tracking the changes? If you are working with a competent editor to whom you have given this option and in whose inputs you trust, then this is one way to get it done faster. You should, of course, edit their changes for them!

In some cases, as the editor, you may not get the source code, or as the owner of the document, you may not want to give them the source. In some of my recent projects, I would get a PDF of the document. This was fine for simple grammar and syntax errors but became onerous when major changes were required. I was forced to send in “sticky notes” of changes. This is probably the least efficient method for the editor, but it does maintain total control by the owner of the document. There are probably a lot of good and bad reasons for using this method, I just cannot think of any good ones.

Being an editor is important and can be rewarding. Having a bad system for rendering changes will ruin the relationship. A good project management truism is to retain your best support people, and especially a good editor. They make your project that much easier to complete on time.

Copyright © Global Knowledge Training LLC. All rights reserved.

David Egan, RHCE, PMP,

is an instructor with Global Knowledge Training LLC. This article was originally published in Global Knowledge’s Management in Motion e-newsletter, named Business Brief. Global Knowledge ( delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.