What is BPMN?

For those new to business process management the acronym BPMN has probably crossed your desk more than once. The first three letters seem pretty obvious, but what does the acronym in whole stand for?

BPMN stands for Business Process Model and Notation. It is a standard that is controlled by the Object Management Group. It is on its 4th iteration and currently is Version 2.0.

BPMN is a way to visually/graphically depict and represent a business process. It is similar to UML, but focuses exclusively on business processes.

Has four basic components:

  1. Flow objects – represent the main components of the workflow (events and activities)
  2. Connecting objects – represent the connections (get it?) between events/activities/artifacts
  3. Swim lanes – represent the responsible parties linked to events/artifacts
  4. Artifacts – provide additional information to the viewer of the model

In follow-up blog posts, we will delve into the BPMN components in more detail as well as discuss the modeling tools that support the standard.

What is business architecture?

The other day I was talking to a friend of mine who had looked at my LinkedIn profile and noticed that I had listed business architecture as skill/job of mine. He had never heard of this discipline and jokingly asked if I design businesses.

My gut reaction was to say “Of course not”, but the more I thought about it I started to realize that business architects do help clients to design/remodel their businesses.

The Object Management Group defines business architecture as:

A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.

This quote aligns very closely with how I view business architecture.

Step 1 – Designing the vision
Blueprints for Willborough Home

The first step in building a house is to draw the blueprint. In order to draw a relevant blueprint you need to determine the purpose of the building. How you design a building is a lot different if you are building a home vs a store vs a factory. Similarly, the way you design a business depends on if you are building a manufacturing business vs a consulting business vs a restaurant. The strategic vision for the business is your blueprint…it guides all future decisions.

Step 2 – Laying the groundwork


The next step would be to clear the land and to lay the foundation. This ensures that the building is stable and has a footing to stand on for years to come. Similarly, when designing/remodeling your business you need to determine what you are building it upon. In this case that would be the strategic planning. This involves performing a review of the business landscape and determining what your goals and objectives are.

Step 3 – Raising the roof

I has...part of a roof

The next main step is to frame the structure. In a building this framing is often done using wood, but in some applications metal is used instead. Again, the purpose of the building can impact implementation. Similarly, when you are building your business you create a framing which in this case is the collection of processes you use to run the business. You need to start with your particular strategy to define your processes…no one approach works for all.

Step 4 – Finishing touches

After you have finished framing your house (or defining the processes/operations) you need to finish the building. This involves putting in windows, doors, etc. In designing a business the finishing touches are the tools that you use to support your processes. Oftentimes, they are IT systems but they can don’t have to be. They can also be change management, training, or other support processes.
House in Boydton, 1912

Of course, there are additional steps between the steps I listed above in building a house (plumbing, wiring, etc). Similarly, there are additional processes needed to fully define your business (organizational structure, prioritization, etc). However, you should be able to see now that the term business architecture is not as nonsensical as many people think it is.

So from now on when someone asks me to define what a business architect does, I will not hesitate to say that we help build businesses.

Consensus is for suckers


We have all heard on at least one occasion that we should strive for consensus in the decision-making process. This sounds simple enough, but is it something we should really aim for?  According to Wikipedia, “Consensus is the community resolution when opposing parties set aside their differences and agree on a statement that is agreeable to all, even if only barely.”  Doesn’t sounds quite as positive a goal now does it?


Why is consensus good?

Consensus is actually a good thing from an execution standpoint:

  • When you have a team that works together to reach a decision, you have a team that is more likely to stand behind the decision.
    • Since they have become a proponent of the decision, they will be more likely to voice their support to outsiders
    • They will work to ensure that the decision/goal is achieved. This is useful when you are incrementally improving a process or product as they will be the team that has influence over the outcome.

Why is consensus bad?

On the flip side of the execution piece, consensus is bad from an innovation standpoint:

  • Dynamics of groups often force consensus because dynamic/dominant characters tend to push everyone to their side and peer-pressure forces the stragglers to join the majority
    • This limits the number of inputs which can reduce the chance of new ideas
  • Innovation rarely comes from consensus because people are not likely to agree on something revolutionary and novel
    • In order to gain consensus you often have to give up on some of the more audacious aspects of the idea



In conclusion, you need to determine your goals of a project when deciding how hard to press for consensus. If you are working to improve existing processes/products then consensus can be a fine goal.

However, if you are trying to shake things up and change the world, then consensus will get in the way of your goals. Do you think Steve Jobs cared about consensus? No, he cared about making something amazing.

That’s not how we did it at my old job

Everyone has heard a colleague utter the phrase “That’s not how we did it at my old job.” Chances are you have said it yourself at one time or another. It is a common refrain and is sure to inspire mixed reactions from those who hear it.

  • Some people may think that the person is bringing relevant information to the table.
  • Others may think that the person is just trying to make themselves seem important.
  • Others may think “that will never work here”

The truth is that everyone leverages past knowledge/experience to conduct their current job. If this was not the case, managers would not care about professional experience. Hiring people who have performed similar jobs helps with the on-boarding process and execution of a job.

However, where we need to be careful is assuming what worked at one company will work at the current one. This is due to the fact that companies are very different from each other:

  • Goals – each company wants to maximize profits, but how they wish to achieve this varies. Some want to increase the amount of profit per project. Others want to increase the number of projects with each client. The goal of the company (and each project) may vary from company to company and applying preconceived notions can be problematic.
  • Internal processes – even if your previous company had the same goals as your current job, the processes that are used to get there may vary. Company formal (Policies, SOPs, and Work Instructions) and informal processes are likely to vary from company to company. Unless you take the time to learn the processes of your current company you are likely to run afoul of them.
  • Stakeholders – over time at your previous jobs you became familiar with your stakeholders and learned what they required of you. At a new job you need to take time to do the same thing. Each stakeholder (internal and external) needs/wants different things. Assuming they all want the same will lead to project and professional stumbles.

Using previous experiences will help you prepare for a new job, but when you join a firm you must be careful to take the time to understand how/why your current company operates. Focus on the goals, processes, and stakeholders of the new job. Taking the time to understand how your current job works will improve how you operate and may also help prevent any missteps.

Did technology kill the project management star?

I was driving the other day and the song “Video Killed the Radio Star” by the Buggles came on the radio. It is a classic song and it got me thinking about how technology impacts all occupations. Television and movie actors replaced radio actors. Bloggers are threatening newspaper reporters. Robots are replacing manufacturing/construction employees. Project managers are not safe from technology changing their discipline either.

The tune has changed

In the early years of the project management discipline, project managers were the central role of the project. They would be the one team members would go to with updates and the stakeholders would go to for answers. Technology is changing this.

-Prior to widespread adoption of project management computer programs, project managers would often be the source of information (time lines, cost, etc.) to stakeholders. Now, project stakeholders can often access a program or file to see the status of the project.

-Prior to these same programs, project managers would have to communicate with the project team members to get updates on tasks and issues in order to manage the project. With technology, the team can log onto a system and update their tasks without having to talk to the PM.

These two factors make many companies view project managers as little more than managers of the tool and thus trivialize the role. For this reason, project managers have to demonstrate the value they bring to the project.

Don’t be a backup singer

To overcome this viewpoint of the field of project management, project managers have to demonstrate the value they bring to the project. Project managers are not simply administrators of the project, rather they are leading/managing the project. This distinction needs to be emphasized and demonstrated to managers and companies.

-When it comes to providing project updates to stakeholders, don’t just show the metrics but rather relate the metrics and project to business drivers and outside influences. Knowing that a project is behind schedule, but is still going to finish prior to the true deadline is much more relevant than knowing the project is behind in terms of earned value.

-Team members are now becoming viewed as a more valuable commodity within the project (no longer simple cogs) and this is great for the projects. PMs need to make sure they work for and with the team to facilitate success. Focus on developing the team members within the course of the project and you will be delivering continued value to your firm/clients.

These are just two ways you can help to ensure that your stakeholders and management team continue to view you (and PMs in general) as a valuable commodity that should be respected.

Let your voice be heard

How are you making sure that the role/position of PM does not disappear in your industry or company? Let us know the steps you are following to improve the relevance of the job and reducing the trivialization by technology.

Put your team in a position to succeed

Every manager wants their team, and the project, to be successful, but this is often easier said than done. There are always obstacles to success and issues that arise during the course of the project. To help ease the pain caused by potholes in the road, you can help your team by putting them in a position to succeed.

I think the main components needed to put people in a position to succeed are:

  1. A clear vision
  2. A stable and mature framework
  3. Access to the proper tools


Provide a clear vision

Company Vision

  • The team needs to know why the company is in business. Is the company just trying to make money or is it trying to improve the world (or industry)?
  • The team needs to know where the company is going. What does the company look like 5 weeks, 5 months, 5 years from now?

Team vision

  • The team needs to know what they are working on.
  • The team needs to know why they are working towards a certain goal.

Individual vision

  • Team members need to know what type of tasks they are going to be asked to do on the project.
  • Team members need to know what they will learn during the project.
  • Team members need to know what the future has in store for them professionally.


Provide the proper framework

Organizational structure

  • The team needs to know how they fit into the puzzle.
    • What is the reporting structure?
    • Who do I go to with questions?
    • Who tells me what to work on?

Project management methodology

  • Methodology choice is unimportant! Choose a methodology and then follow it.
  • Educate the team on the methodology you are using for the project.


Provide the proper tools

Technical resources

  • Make sure the team has adequate technical resources:
    • Computers
    • Software
    • Materials
    • Team/meeting space
    • Snacks…all team members appreciate food

Human resources

  • Make sure you staff the team adequately
    • Enough resources
    • Qualified resources
    • Motivated resources
  • Make sure you develop the team via training and personal development initiatives

Following the above steps may not guarantee project success, but not following them certainly can doom a project. When the team knows that you are committed to them and the project, they are more likely to return that commitment in kind. Remember, you are all in this together, and you depend on them just as they depend on you. Do what you can to put your people in a position to succeed and you are more likely to succeed yourself.

Iteration Planning Checklist

My company recently completed our most recent iteration planning session. It was an eye-opening experience for most of our team had not been part of an iteration planning session before. Below is a checklist that teams can use to help ensure that their iteration planning meeting is successful.

Before the session:

  • Product backlog has been finalized
    • All backlog items have been assigned a stack rank by the Product Owner
    • All backlog items have been assigned their story points by the Project Team
  • Project Team has been prepped
    • Team has been trained on basic Scrum processes/roles
  • Situation has been analyzed
    • Outside factors have been reviewed and impact on team has been documented
    • Project team member capacity has been evaluated/documented
      • # of hours per day for each worker
      • # of days each worker will be available during the iteration
  • Meeting logistics have been finalized
    • Meeting location has been booked for the entire day
    • Project team has been made available for the entire day
    • Lunch has been ordered

During the session:

  • Session was initiated
    • Welcome team to the meeting
    • Review iteration planning process
  • Backlog is triaged
    • Tasks are defined for each user story
      • Task duration estimates are documented
      • Task owners are documented
  • Agreement is reached
    • Project team and product owner agree on the plan of attack
  • Meeting is evaluated
    • What went well and what could be improved

After the session:

  • Iteration tracking system is set up
    • Allow tracking of all iteration tasks
  • Daily scrum meetings are set up

Following the steps above should help make your iteration planning meeting your most successful yet. Do you have any other tasks/items that you feel contribute to the success of your iteration planning meeting?

It’s ok to ask for help

We have all witnessed the hot-shot project manager who jumps head-first into every project and never declines the request to lead a new engagement. Sometimes this PM manages to eke out success from every project, but this is the rare situation.

Far more often, the PM who keeps trying to juggle more and more projects is bound to fail and wind up with projects on the floor. This is because all of us, no matter how skilled, have a pre-defined capacity.

This capacity varies from person to person, but no one can manage unlimited project or priorities. We have the ability to start many projects and get the ball rolling, but once the project progresses the time and intellectual commitment dramatically increases.

As each project requires more and more personal resources, PMs try to find ways to compensate.
These include:

  • Delegating more and more work which they should be doing
  • Taking shortcuts in terms of documentation or communication
  • Pushing out deadlines

None of these solutions is ideal or, in many times, acceptable. PMs need to be able to focus adequate internal resources on every project they are managing.

Hopefully your company performs resource planning/leveling and never puts you in a position where you are over-allocated, but in talking with other PMS and reading other blogs I seem to get the distinct impression that many of you feel like you have too many projects.

So what is a PM to do? Increase communication!

With project stakeholders – Ensure that you keep all stakeholders informed of the status of your projects at all times. If things are running behind schedule let them know. If you are unable to meet a commitment let them know. If you need more time for a deliverable, ask for it. No stakeholder likes to hear about project issues, but they are much more upset if you hide the issues from them.

With your management – If you have conflicting priorities let them know. If you are unsure how to proceed let them know. Most importantly, don’t hesitate to ask for help. Saying you need help is not a sign of weakness. Rather, admitting that you are not invincible is one of the bravest things you can do because it shows that you understand your limitations.

These ideas are not silver bullets that will solve all project problems, but hopefully they can help you with some of your project issues. If you have other ways you handle situations when you feel you are losing control, please add a comment to other readers can benefit from your experience.

Starting is easy, finishing is hard

I was recently listening to a podcast when a quote really struck me as being central to the life of a project manager. The quote is by Jason Calacanis and reads “Starting is easy, finishing is hard.” He was referring to his experience starting and running several successful companies, but the quote applies equally well to project management.

Project managers are evaluated not when the dealer is shuffling, but rather when the project is over and all the cards have been played. This means that you must work your hardest throughout the entire life of the project. I have talked to some PMs and their passion is in creating the project schedule or gathering the stakeholders together in the beginning of the project. These tasks are important, but they ultimately do not decide the fate of the project.

The project outcome is determined by the consistent and continued effort of the PM and the project team. The overall execution is what matters during the project, not the ideas behind the project or the preliminary groundwork that is laid. As such, a project manager should dedicate most of their time to ensuring that the execution phase of the project is successful.

I know that many PMs state that the initiation phase is the bulk of the work and that it is then smooth sailing until the completion of the project. However, it is far too easy to get derailed if you do not dedicate adequate vigilance to monitoring the project. Do not overlook the details of the project or you will be reminded of them during the uncomfortable lessons learned meeting that folllows.

If you commit to working the plan during the entire project and dedicating energy and effort to control and monitoring, then you will have a greater chance of project and career success.

Top Three Reasons Scrum Doesn’t Work

You have likely heard many reasons why you should ditch waterfall methodologies for managing your projects and adopt Scrum instead. However, the following three situations are going to guarantee that scrum will not work at your company.

1) Lack of management buy-in

In order for scrum to succeed within your organization you need to have the support of management. Scrum processes and artifacts are quite different from what most managers/executives are familiar with. If your management team is not comfortable with the new process then they are likely to become an impediment (albeit an unwitting one).

Solution: If you want your management to be onboard with scrum and even champion it to other executives; you need to provide them with ammunition. In this case, the ammunition is knowledge; knowledge of the scrum processes and examples of companies which have successfully used scrum to improve their project success rate.

2) Not empowering the team

Scrum works only when the project team is empowered to use their insight and experience to make the appropriate decisions. Treating the team like a bunch of children (like many project managers do) does not motivate the team to perform to their best ability. You need your team to work at 100% and use their creativity and passion to push the project to completion.

Solution: As the scrum master you need to focus on serving the team rather than leading them. Your primary mission is to make sure the team has what they need to succeed. As the old saying goes “Give a man a fish…” well, you know the rest.

3) Viewing Scrum as a light-weight methodology

Many teams jump to Scrum because they feel that it is an approach to a project that just lets them code/build/etc. and not have to worry about processes or documentation. The teams that adopt Scrum because of this misconception are doomed to fail in their adoption of Scrum and in the execution of their projects.

Solution: Set realistic expectations that Scrum is just as rigorous as traditional methodologies. While traditional methods require a great amount of documentation, they usually offset this by reducing the amount of time the developers are in meetings and the amount of communication the team is required to create. Scrum on the other hand may reduce the initial documentation expectations, but it requires the team to be available and increase the frequency and immediacy of communication. This can be a big change to developers who sometimes camp in front of their monitor for a day or two at a time and do not talk to other team members.


While the challenges above are legitimate ones, they are by no means insurmountable. I have provided some basic ways you can counter the bad habits and situations you may encounter. Scrum is a powerful tool for creating change within an organization/project and the effort to implement it is well worth it.