TAPUniversity has partnered with gnomio to launch its learning management system ahead.  Additional must-have features include test bank expansion and knowledge sharing tools.  An innovator in online project management training since 2006, this partnership ensures our delivery keeps paced with your learning needs! Just click on the TAPUniversity LMS* on the menu to access the new TAPUniversity.

Also your first touch point with TAPUniversity is now our public content.  Dig in, learn, share, give your opinion and engage with us as we TAP into the future!

TAPUniversity Blog surpasses 100,000 visits!

Time for a little celebration.  Today the TAPUniversity blog surpassed 100,000 visits or reads.  Over the last two years our blog readership and contributions have grown steadily.  Several hundred professionals check in each day and explore over 400 articles and growing.    We’ll continue to publish and hope you’ll share in our exploration of the Management Nexus as well; from agile, to business analysis, kanban, leadership, lean, management, project management and six sigma. 

Thank you!

David Kohrell, editor, TAPUniversity Blog and Management Nexus

As well as blogging for Tap University, I am also a member of the team behind Pragnalysis.com, a website which provides free BA tools and templates to the BA community.  I’m extremely excited to announce the launch of our latest initiative :  A fully functioning, open source, requirements management tool.  The tool will be completely free to use and re-distribute, and a Beta version can be downloaded and used immediately:

You can download the ReqLine Requirements Management Tool now by visiting http://www.pragnalysis.com

Full details of the tool can be found on the website, however its features include:

• A common repository for all requirements
• Ability to maintain individual requirements, along with their status (draft/signed off)
• Ability to define requirements groups – releases, iterations etc
• Reporting functionality including various dashboard-reports and the ability to export a requirements catalogue
• Logging and monitoring of risks, issues, assumptions and dependencies
• An intuitive way to link requirements back to high-level goals and objectives, ensuring that stakeholders consider business value throughout the project
• Built in change-control and impact analysis functionality
• Project glossary

It has been very exciting to have been involved in the creation of such a useful tool. ReqLine is a requirements management tool designed for BAs by BAs, and we’ve combined the experience of a number of BA practitioners to create this first Beta release.  The Beta version is a single user, single machine version – but it is anticipated that future versions would be multi-user and server based.

Please try the tool, and provide feedback directly to me or any other member of the Pragnalysis team.

For more information, please visit http://www.pragnalysis.com

I look forward to hearing from you!

Related articles

• How to Find Where New Process is Really Needed (tapuniversity.com)
• 34 Business Analysis Techniques from The IIBA (tapuniversity.com)

Business Rules can be fun!

Business Rules.  Universal definitions or process descriptions that transcend a single use case or process flow.  A little bit bigger than a glossary definition (such as income range, gender, ethnicity) but not quite a usage scenario in its own right.  Business rules as they’re refined, adapted and updated are invaluable requirements assets – they really can help collect and focus attention.  Customers and sponsors like them because they provide a connecting point in the IT world.  For much of the same reason developers and quality assurance team members like them because they help maintain focus and provide an opportunity to write code once, reuse many times!

Some sample business rules include:

1. Payment receipt
2. Payment authorization (ACH, debit, credit card)
3. User login validation
4. Account balance
5. Purge record

The analysis includes creating those business rules and determining which processes benefit from their reference.  Time spent to gather and update business rules is rewarded with consistent and expedited delivery!

Related articles

• 34 Business Analysis Techniques from The IIBA (tapuniversity.com)
• Business Analysis Technique #26 – Scenarios and Use Cases (tapuniversity.com)
• Business Analysis Technique #11 – Focus Groups (tapuniversity.com)

One a hundred problem tracking tools and a personal favorite - BUGZILLA!

Problems, issues, bugs, defects, action items, punch list, clean up tables – so many synonymous terms for the same underlying concept – tracking known “stuff” and making sure it gets resolved before a product or service is released.   While risk management concerns the known- unknown, management reserves address unknown  -unknown, problem tracking is smack dab in the middle of the here and now.  It’s real!

As there are multiple ways to describe it, there are also dozens of tools to track it.  Over the course of my delivery I’ve used Defect Tracker, Bugzilla, RUP, Spreadsheets (Lotus, Quattro Pro, Excel), Public Folders (Microsoft), Silk, Mercury Tester, Sharepoint, Quick Place and large flowing legal pads with a thing called a pencil.

While using those tools I’ve found a few simple tips help to keep my and my team’s attention focused.  I use the term “AIR”.  It helps breath some fresh air across this stuff and make sure the mildew does not mire your project down!

1. Create a category for Action Items (issues or problems that have been assigned to a single person with a specific date)
2. Create a category for Issues / Problems (issues or problems that are known and may transcend your current project or change order)
3. Create a category for Risks (issues or problems that have not yet occurred but you’ve deemed may occur).
4. For Action Items and Issues / Problems assign an impact rating if it is not addressed.  The probability is equal to “1″ since it’s a known.  The decision support is how much that issue will impact your project.  Higher impact issues rise up in their priority for fast assignment to an Action Item
5. Keep the AIR up-to-date with any project scheduling tools you might use (Project, Clarity, etc) – a project schedule is a collection of Action Items (aka tasks).
6. Review the most pressing, the top 10 action items, issues/problems and risks with your team regularly.  That could mean reviewing those once a week or, if you’re in the midst of an Extreme Programming or SCRUM or similar Agile approach, every day.
7. Use this to help guide your product and service launches.  Transfer any lingering problems/issues to the operational support team.

Related articles

• Considering a new keyword for Bugzilla (whereswalden.com)
• Project Health Check : 5 serious project warning signs (tapuniversity.com)
• Business Analysis Technique #26 – Scenarios and Use Cases (tapuniversity.com)
• How to Find Where New Process is Really Needed (tapuniversity.com)
• 22 Free Tools for Data Visualization and Analysis (pcworld.com)
• Business Analysis Technique #32 SWOT Analysis (tapuniversity.com)

Focus, find, and determine your root cause

But I’ve learned that the reality is that you will never be able to apply everything you’ve learned. This is because either it’s not needed or the organization can’t handle it. Every organization is different and has a different set of problems. What worked in one place, may not work in another.

What I’d like to talk about today is how to determine what is really needed process-wise when you first start a new project in a new culture. I’ve seen lots of Project Managers start new positions and want to apply everything they’ve learned from the PMBOK, only to actually slow things down and create inefficiency, and even, in some cases, bad will. There’s a stereotype out there about the ‘check the box’ Project Manager (PM). Someone who has all the correct process, but none of the wisdom to really correctly use process and tools to fantastic result. I don’t want you to become one of those PMs. I want you to become that indispensable, brilliant PM who analyzes the situation and correctly applies the tools.

You may be familiar with the Pareto rule. The Pareto rule says that 80% of effects come from 20% of the causes. In practice, this means that if you have problems on your project, most of them have the same cause or set of causes. It’s like there are ‘source’ causes for most of the problems that you see.

Success lies in addressing that 20%, the source causes, and neutralizing them before they balloon into 80% of your problems.

Here’s a process I’ve used to discover that 20%. Let’s call it the ‘The Real Need”  process. The goal of this process is NOT to apply everything in a model. The goal IS to apply the right process, in the right amount and to the right situation.

The Real Need Process:

Step 1: Force Yourself to Observe :

For people like me, sitting back and watching is really hard. But, I’ve fell flat on my face so many times racing to apply process, that I’ve finally learned to sit back and watch. I don’t mean don’t do your job. I mean, before you suggest brand new processes, watch and wait for a while.

Do this for about a week to a month – depending on the culture of your organization.

Step 2:  Analyze and Evaluate the Stream of Artifacts and Behaviors:

As you read documentation, or watch behavior, or read emails, start to breakdown what your next step would be according to the model. So for example, say you receive an email from a team member about how the client is angry with something. Most Project Management models would encourage that you take action. They would advise perhaps discussing the issue with a SME, maybe adding the issue to a list of risks to monitor. Let’s not forget potentially adding the issue into the change management system, and ensuring that the issue is added to action items for further discussion.

That’s a whole lot of behavior that you could do, and that the model predicts are best practices, because if you don’t do these things, the project can go into a lot of crazy directions, most of them unfavorable.

The key here is to document what the model says you should do, but not to do any of it, yet.

Instead, watch and see how the organization responds.

Step 3: Watch How the Organization Responds:

There is value in the repeated pathways of human behavior. Human beings are capable of developing success behaviors, which have been learned from past failures. When you first come into an organization, you probably don’t know those behaviors. Most of them aren’t documented. So what you may have interpreted as a failure behaviors based on your previous experience may in fact be a success behavior in the new environment.

Likewise, what the product/process model predicts as failure behaviors may in fact be success behavior in the new environment.

So, armed with your notes from step 2, watch the behavior and outcomes of the stream you observed in step 1. The organization will do two things; a) what you think they should do and b) what you think they shouldn’t do.

Step 4: Take Action:

For anything that is b) what you think they shouldn’t do, that winds up not causing further problems, strike that from your list of things to address immediately. This means that it’s not part of the 20% causing the 80% of the problems. In other words, the model (and your previous experience) may have predicted failure…but failure didn’t happen. Therefore, there’s some wisdom of experience in the behaviors of the organization that you should make a note to learn.

However, for anything that was a) what you think they should do that they didn’t do, and that led to a problem, focus in on that. That is your golden entre into solving problems. In that case, your instincts, and the model, predicted that a problem would occur. And because you’ve been learning, and have process and project tools at your disposal, you can rapidly suggest and hopefully implement a solution.

Conclusion

This isn’t a perfect way to get at all problems, but it’s a start. And it will prevent you from applying process where process probably isn’t needed. The idea here is to help you eliminate extraneous information by focusing on actual observed outcomes rather than on theory alone. This approach enables you to quickly find the failures, and use the theory for what it was meant for…project success.

by Michiko Diby, Blogger, Kosmothink

Related articles

• Radha.L, PMP: Project Management and ABC’s of life (pmhub.net)
• I’m Not Gonna Force Agile On You (magwep.wordpress.com)
• Process Improvement Programs – When You’re in Need of One? (corporategeek.info)
• Business Analysis Technique #26 – Scenarios and Use Cases (tapuniversity.com)
• Project Health Check : 5 serious project warning signs (tapuniversity.com)

Projects benefit from "health checks". Look out for warning signs!

Sometimes when working closely on a project, it is difficult to see the warning signs.  However, it is worth carrying out a project “health check” every now and then, to check for danger signs.  If you see any significant warning signals, then you might need to take some serious (and unpopular) corrective action.  Five such signals are discussed below:

1. Experts are ignored:

Projects that are in trouble may choose to selectively ignore concerns raised by experts.  Inconvenient truths tend to be “parked” or “explained away” without further analysis. Even worse, the commitment of those raising the concerns may be questioned.  This tends to have an extremely negative effect – morale of the project team is likely to suffer as they don’t feel listened to.  And even worse, they may feel disinclined to raise concerns in the future.

Organizational solution: Organizations and projects should encourage their experts to speak up.  It is generally better to know the “cold hard facts”, and every member of the project team should be encouraged to share their constructive concerns. This issue will cease if an organization proactively fosters accountability, whilst also fostering a culture of continuous improvement and learning. And remember: A project maverick is not a heretic!

2. Business cases are “re-worked”:

Business cases should be a central tool used by organizations to ensure that only profitable projects are run.  In some cases, other “hidden agendas” may be at play, and the project team might be asked to use some “creative licence” to make a business case look profitable.   This often happens in organizations where there is little accountability for the realization of project benefits.

Organizational solution: Organizations can stop this happening by encouraging and valuing true accountability, from project sponsor downwards.  The sponsor should be accountable for the delivery of benefits as well as the delivery of the project. Each project team member should be empowered to challenge decisions which seem to contradict the business case or scope.  Empowerment, accountability and integrity are the three key values that will prevent this situation from occurring in the first place.

3. Unclear objectives or scope:

One of the most serious warning signs on a project is a lack of scope.  If you start work on a project, and scope or objectives are not clear, then you are in for a rough ride.  This suggests that there has not been adequate attention paid to the foundations of the project, and in most cases it will be beneficial to step back and agree the scope.  If this doesn’t happen, there is a significant danger that the solution will be delivered in a way that does not meet expectations, and does not maximize return on investment.

Organizational solution: If scope or objectives are unclear, the only way to address this is to firm them up.  Good governance should stop this happening in the first place, but a project has slipped through then the project team should work to reach a consensus, and then move forward.  This might cost time in the short term, but it will save significant time in the long term, as it reduces the risk of misunderstandings and miscommunication over scope.

4. “Risks and issues” only exist on a log:

Embedding risk management techniques leads to more successful projects.  A significant project warning sign is RAID (risk, issue, assumption, dependency) logs that have not been maintained and are not being followed up.  This suggests that risk management is happening only “On paper”.   Each risk should be owned, and should have a defined strategy for dealing with it.  If this isn’t the case, then corrective action should be taken.

Organizational solution: The only solution to this problem is to ensure the project manager is actively controlling risks, issues, assumptions and dependencies.  If they are not, organizations should encourage and compel them to do so!

5. The project schedule doesn’t exist or is out of date:

A project and programme schedule should be a central communications tool.  Ultimately, this is a central tool that ensures everyone knows what tasks they need to complete, and what the deadline is.  A great way of carrying out a health-check on a project is to ask a random member of the project team where the project schedule is located, and ask them to show you a copy.  If they can’t, or if it is out of date, then you have uncovered a communication problem.

Organizational solution: Good governance and project discipline should ensure that all projects have a schedule that is fit-for-purpose.  Ask questions to ensure that a schedule is in place, and if it is absent then ensure it is created as soon as possible!

Conclusion

I see these warning signs as the “Big 5”, though there are many others that may surface on a project, and as change practitioners it’s important for us to recognise them and take any necessary corrective action.  Unfortunately, the corrective action is rarely palatable.  The most important thing we can do is to constructively challenge ourselves and our project colleagues, and ensure they are dealing with the cold hard facts.  We should escalate where necessary, and ensure that facts are not hidden and experts are not ignored.

Positive and proactive challenge and escalation is rarely popular, but is necessary to ensure that organisations get the best from their projects.  Good luck!

Have you worked on projects and seen these (or any other) warning signs?  Do you have any further examples?  I’d love to hear from you – feel free to contact me directly or leave a comment below.

About the author : Adrian Reed is a UK based Lead Business Analyst, author, speaker and qualified practitioner of change. If you enjoyed this article, you can follow Adrian on Twitter or read his personal blog.

Related articles

• Early Signs your ERP Implementation is failing, part 2 (boverstreet.wordpress.com)
• There is no ‘I’ in Team: The Basics of Teamwork (noupe.com)

Why couldn't I have invented this and got the patent $

The whiteboard.  The dry eraser.  The multi-color pens.  The overbearing meeting participant.  Those four things often come together when thinking of brainstorming.  It’s a technique among multiple management nexus disciplines and at the heart of agile, business analysis and project management. It can produce great results from a team.

The Business Analysis Body of Knowledge (2nd Edition) addresses it in section 9.3. The Guide to the Project Management Body of Knowledge references brainstorming as the tool and technique, Facilitated Workshops, for Collect Requirements (5.1) and Define Scope (5.2).

Brainstorming is also technique, despite years of coaching and training to improve its effectiveness, that can go easily astray.

An innocent enough brainstorming session can quickly turn into a diatribe from a “power figure” or as easily slip into a real life parody of the television show “The Office“.

When effectively facilitated brainstorming sessions can unleash a wealth of ideas, strategies and enthusiasm for a team.  One approach that helps keep the brainstorming in the positive side is nominal group technique (NGT).  And one little tool that makes NGT work is the ubiquitous post-it note (aka sticky note).   Here are some steps for NGT – we’ll use deciding features for a new Twitter interface as an example:

1. Gather group together – preferably less than 12
2. Distribute 10 post-it notes
3. Keep a supply of extra post-its handy
4. Have participants write their ideas for the new Twitter interface, silently, on their post-it.  One idea per post-it (people often forget the 1 per post-it rule, so gently remind them
5. When everyone has a chance to capture their ideas, call for confirmation that “we’re done”
6. Have each team member read 1 idea at a time and go around the table or room
7. Clarification questions are OK, judgment questions are not
8. Continue going around the room until all post-its have been shared – one at a time
9. When all post-its have been shared, ask “what’s missing”?
10. Gather up the post-its and have the group arrange by topic or association – for example #trending topics, social network plugs, etc.  This leads wonderfully into another technique called affinity diagramming!

Related articles

• 34 Business Analysis Techniques from The IIBA (tapuniversity.com)
• Business Analysis & Decision Making (thinkup.waldenu.edu)
• Management “Nexus” – the intersection of multiple disciplines (tapuniversity.com)
• The Secret to Good Brainstorming Techniques (cgreyes.wordpress.com)
• John Reiling, PMP: Systems Thinking in Project Management (pmhub.net)
• Risk Priority Number (RPN) (tapuniversity.com)
• Risk from a Business Analysis Perspective (tapuniversity.com)
• Brainstorm your way to PR success (publicrelationssydney.com.au)
• Make the most of your brainstorming (smartblogs.com)

OK, ok, OK - the Apollo 11 mission was much bigger deal!

We reached 400 posts yesterday. Our blog is primarily targeted for education, learning and conversation. While we do need some money to keep the lights on, we try to keep the commercial pitches and “monentization” to a minimum.  Thank you everyone who has participated, read and engaged with our blog since late 2008!

Our author roster is growing and we have appreciated the contributions from Adrian Reed and Meryl Rowley this year. Several more authors will be sharing soon!

And, here’s to the next 400 topics across the management nexus of:

• Agile/Scrum
• Business Analysis
• Business Process Management
• Contract Management
• Earned Value
• IT Compliance and Auditing
• Information Technology Information Library Version 3
• ITSMF
• Lean Software Startup
• Lean Six Sigma
• Project Management & Portfolio Management
• Risk Management
• Six Sigma
• Virtual Teams

Thank you!

David Kohrell, MA, PMP®, CBAP®, CISA®, MCP®
Seminar Leader TAPUniversity, Editor TAPUniversity Blog.
http://www.linkedin.com/in/dkohrell

Related articles

• Management “Nexus” – the intersection of multiple disciplines (tapuniversity.com)
• Certification Exam Feedback: PMP , CBAP , CISA , CISM , CISSP , ITIL , CSM , Lean Six Sigma (tapuniversity.com)
• John Reiling, PMP: Systems Thinking in Project Management (pmhub.net)
• Risk from a Business Analysis Perspective (tapuniversity.com)

What you see?

This adjustment allows for continuous process improvement.  Teams don’t allow themselves to become stagnant or stale – they change and become better.  The manifesto doesn’t proscribe how often and allows some leeway.  The definition of “at regular intervals” provides sufficient guidance that this reflection on how to become more effective is more than an annual review.

Some questions that can help shape that review are:

• What strengths do we have as a team, opportunities, threats and weaknesses (SWOT analysis)?
• What insights can we gain from the most recent software release?
• What are our customers telling us?
• How can we become better?
• What mistake have we made that we can learn the most from?

Reflection and adjustment can prove powerful for accelerating delivery of great software and developing great teams!

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Related articles

• Agile Principle 11 – Self Organizing teams produce best architectures, requirements and design (tapuniversity.com)
• Reflections on the 10 Years Since the Agile Manifesto (allaboutagile.com)
• Agile Principle 6 – Face to Face Interaction (tapuniversity.com)
• Agile Principle 10 – Maximize work NOT done! (tapuniversity.com)
• Agile Software Development Turns 10 (devx.com)
• Agile Manifesto, made more agile (zdnet.com)
• Agile Principle 8 – Constant Pace of Development (tapuniversity.com)