Project Charter Template

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

Use this project charter template to create the charter at the end of the project initiation process. This is after you have the scope information, the statement of work (SOW) from the sponsor and before the detailed planning begins. It includes the following:

  • scope
  • major deliverables
  • assumptions
  • constraints
  • risks
  • required resources and
  • change control.

 Starting work is still a ways off and this is the best time to discuss potential risks and problems with the project sponsor. You should also discuss your authority to assign work to borrowed team members and the availability of those resources. You need to be sure the project team will show up to do the work when they’re scheduled.

Other issues you should address are the scope’s underlying risks and assumptions. You can use the project charter template to identify those assumptions and risks. Then talk with the sponsor and stakeholders about how you can avoid or mitigate the risks. You should do this before the detailed planning begins. It’s easier and cheaper to include responses to the risks now than it will be later on. The project charter template should also include a process for making changes to the project plan. Everyone needs to understand that there is a process that includes an evaluation and approval before the plan can be modified. Project Phases Main Page

Project Charter Template: Cross-functional Authority

The project charter template should also address cross-functional authority issues. But that issue often gets lost among the assumptions and “mission statement” narrative. Even when PMs generate a concise decision-making document, they are vague about the authority they need to successfully manage the project. They want to avoid conflict over this touchy subject. But if you are a savvy PM, you know this conflict is inevitable. It is better to have the debate on authority now than to wait until the project is late and over-budget. It looks like you’re shifting blame if you explain slippage by finger-pointing at cross-functional resources. You need to specify in the  project charter how you will assign work to people from across functional or organizational borders. You should design an achievement network that maps the lines of accountability and shows the sponsor and stakeholders where you need authority. You must make crystal-clear assignments to the team members that are measurable achievements.

You can’t expect to have dedicated resources you can manage as subordinates for all the project project charter templateassignments. So you have to make careful choices. You should ask for direct authority for assignments that are:

  • on the critical path
  • are high risk
  • have a long duration
  • require rare skills.

You can live with indirect authority and even settle for “in the hopper” authority on shorter, less critical assignments. This means your request for resources goes “in the hopper” with all other demands for resources. If you ask for too many dedicated resources, it will backfire. You’ll be stuck with “in the hopper” authority for every assignment on your project.

Project Charter Template: Project Sizes

The project charter template requires some information gathering.  You have choices about which elements to include.  You also have to decide how much detail to give on the elements. As we said earlier, everything flows from the Statement of Work (SOW) that the sponsor  issues to get the project started. Let’s look at initiating a project, the project charter template document, and how you’ll complete the pieces for projects of varying sizes:

Tier 1: Small Projects – Done within an organizational unit. Your manager or your boss is the sponsor

Tier 2: Medium Projects – Projects that affect multiple departments or are done for customers/clients

Tier 3: Strategic Projects – Organization-wide projects with long-term effects on all departments.

Project Charter Template: Identify Stakeholders

Tier 1: Small Projects: This step is not necessary on an in-department project where the department manager is the primary stakeholder.

Tier 2: Medium Projects: You must make an effort to identify the stakeholders in multiple departments. This avoids getting surprised by late arriving requirements that must be added.

Tier 3: Strategic Projects: This step is a process of surveys and interviews to identify internal and external stakeholders who may be affected by the project. Their requirements must be considered.

Project Charter Template: Business Case

Tier 1: Small Projects: This step is not necessary because formal project approval is not required.

Tier 2: Medium Projects: Organizations with sound project management processes require a business case to justify a project’s priority versus other projects in the portfolio.

Tier 3: Strategic Projects: The level of financial and human resources requires detailed documentation and justification of the strategic impact of the project.

Project Charter Template: Scope, Deliverables  and Risks

Tier 1: Small Projects: A 1-page overview of the plan that includes the scope, deliverables, risks, resources and PM authority.

Tier 2: Medium Projects: The project charter document addresses the project acceptance criteria, business justification and rough estimates of the resource requirements (human and financial).

Tier 3: Strategic Projects: The size of the investment in these projects usually requires extensive documentation of risks, benefits, impacts on other strategic initiatives and on the total organization.

Project Charter Template Summary

Depending on your environment, the project charter template can include many components. The charter usually has a statement about the scope or statement of work (SOW) and the principal risks and assumptions that underlie the project plan. It should also include the processes for identifying and approving changes to the project scope. In addition, the project charter template should specify what resources the project plan requires and the project manager’s authority to manage those resources. You can learn how to prepare and present your project charter in our Project Management Basics course. You’ll work privately with your instructor and have as many e-mails, phone calls and live video conferences as you need.

You learn all of those skills in our online project management basics courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  More information on the lean project methodology

Take a look at the courses in your specialty. At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

More on Decision Making Data,

Risk Management – Video

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

It’s difficult to persuade executives to invest time and money on risk management to avoid or limit risks. They prefer “being ready to react” when bad stuff happens. They think that is cheaper than spending money on what they often see as a bureaucratic process with pointless meetings and lots of paperwork. So their decision is to “keep our eyes open for trouble.” They don’t want to waste money, and possibly delay the project’s start, by identifying and planning for risks. This is a poor decision. Even a small amount of risk management, as little as one hour, can have a significant payback if it allows you to avoid one or two problems.

Project managers need to make the case that even a small amount of time on Risk Management, like a lunch meeting with the right people, can repay the investment by avoiding problems. The best way to make this point is to discuss some recent project failures. You can cite the problems that brought those projects down and explain how a bit of risk management, response planning and early problem solving might have saved the day. Risk Management Plan

Risk Management for Different Size Projects

After you gain approval for a Risk Management effort, you need to move ahead carefully with a bare bones approach. In the beginning, you need to build your credibility and that of risk management with a handsome return for the risk investment. You also need to use the correct set of risk management techniques to fit the size and scale of each project. One size does not fit all. You need to tailor your approach so it fits the project and yields a high return on the investment.

Watch this video on risk identification.

Risk Management: Risk Identification

There are five components in the full Risk Management process. But you will rarely use all of them.

  1. Risk identification – identify those positive and negative risks that might affect the project
  2. Qualitative risk analysis – fast, low-cost risk evaluation with no research or data gathering
  3. Quantitative risk analysis – slower, expensive research into the risk’s probability and impact
  4. Risk response planning – ways to mitigate, avoid or eliminate the risk’s effect. Risk Strategy
  5. Risk monitoring & control – monitoring so you can launch a risk response when needed.

You must control how much time and money you spend in each of these steps. Depending on the project, you may entirely skip one or two of the steps to cut the time and cost. You will do the less expensive qualitative risk analysis on most projects. On a small project, you can invest as little as an hour in total on risk identification, qualitative risk analysis and risk response planning. You will spend only what it cost to buy coffee for the group. But on some projects, your qualitative risk analysis might deserve 6 hours of work and include getting ideas and data from a dozen stakeholders.  On larger projects with massive risks, you may do all five of the steps and spend weeks or months and thousands of dollars.

Risk Management: Examples of Three Plans

Let’s look at some Risk Management examples and see how you might use them for three different size projects:

  1. A project done within a department where the PM and team all report to the project sponsor
  2. A cross-functional project that affects several departments in an organization
  3. A strategic initiative that affects all areas in a large organization

Project #1: Risk Management for a Small Project

In assessing the situation, you remember the boss made a big point about starting fast and avoiding a lot of project management paperwork and unnecessary meetings. So you decide to use a very small risk management process. When you finish the discussion about the project scope, you ask the boss, “What are the major risks you think we face in delivering that scope?” The boss gives you three examples of risks that had damaged similar project efforts. Then you ask, “What do you think we can do on this project to avoid having our efforts hurt by the same kinds of risks?” The boss suggests that you avoid the problems with inter-department cooperation by involving the other departments early in the effort. He also points out that you can avoid delays resulting from people not coming to meetings by letting people attend by video conference. Finally, the boss suggests that you record the video conferences (after letting everyone know you’re doing it) and send the video to the people who couldn’t attend the meeting. You thank the boss without explaining that the two of you have just completed risk identification, qualitative risk analysis and risk response planning. All you say is that you will add those elements to the project plan and schedule.

In this example of a small project, you asked a couple of open-ended questions to tap into the boss’s experience. You completed a very small Risk Management process. The project plan will now include risk responses and risk mitigations that may help this project avoid some known risks.  Project Risk Management

Project #2: Risk Management for a Cross-functional Project

This somewhat larger project involves stakeholders from several departments in the organization. Many of them may also be project team members. In a meeting with all the identified project stakeholders and team members, you describe the scope of the project and the major deliverables. Then you ask the people to think about risks that could affect each deliverable. Your project charter has five high-level deliverables and you focus the discussion on each of those. You limit the discussion to identifying the risks and their ideas about those risks. You ask them to hold off on defining the kind of risk response they think is appropriate. You also discourage people from criticizing any of the suggestions or evaluating their likelihood. In qualitative risk analysis, you want the group to come up with a list that’s as long as possible.

With your list of identified risks, you’re ready to begin qualitative risk analysis. You will assemble your group and focus on screening the risks using relatively quick and inexpensive qualitative techniques.  You want to rank the risks in terms of their likelihood and potential impact on the project. You use qualitative risk analysis as the only analysis to support risk response planning. The project’s scale does not justify the time and cost of quantitative analysis. Neither the boss nor the team members have any experience in Risk Management so they will subjectively rate the impact and likelihood values for your risk and impact analysis.

After they have completed their task, you have a list of 14 potential risks. You then say, “Here’s a form we’ll use to get everyone’s assessment of the risks we face on the project. We want to describe each risk in terms of two separate dimensions:

  1. The probability or likelihood of the risk event occurring
  2. The impact it will have on the project’s costs or finish date or both, if it occurs.

We’ll use a simple scale of 1 to 6 with three choices for likelihood and for impact. Low – meaning very unlikely to occur or a small impact.  High – meaning very likely to occur and a large impact. And Medium – meaning between those two extremes.”

Figure 1 – Risk Management Qualitative Risk Scores from Team Members

You get ratings from the team members: 1=Low 6=High. Then you enter them in the form and have the qualitative risk analysis results below.  Using this data, you would select a risk response.

1. Risk event 2. Likelihood 3. Impact 4. Risk Response
Name Medium High Low Medium High Low

Type of Response

Turnover among engineers is over 20%


 5  1  1  6


 Transfer, Mitigate, Avoid 0r Accept with Contingency

Figure 2 – P/I Results for Three Risks 

    Magnitude        Low                     Medium                                   HighProbability


Engineer turnover
 Medium      Don’t use new procedure


Trouble Reports increase

Then you say, “We all seem to agree that while we have several risks, only one risk has both a high probability and a high magnitude and that’s the risk of engineer turnover.

The boss says, “I thought this risk stuff would be a waste of time but I’m already thinking of things we can do to reduce engineer turnover. That is a surprise I wouldn’t want to hear about right before the end of the project.”

For this department project, you engaged the sponsor and the team in risk identification and qualitative analysis. Now you’re ready to move on to risk response planning.  The aim of risk management is to take action by forming risk responses before the risks do any harm to the project. It doesn’t require fancy risk management techniques, just an effective process.

Project #3: Risk Management for a Strategic Project for a Larger Organization

Project Situation:

  • The project risk management plan calls for using qualitative risk analysis as a screening tool to select the risks that you will put through quantitative analysis. You anticipate analyzing a dozen or more risks with quantitative analysis.
  •  Three committees will do qualitative risk assessment. Each one is focusing on a particular market segment the company serves.
  • The risk steering committee will make a final decision about which risks go on to quantitative analysis. That committee includes the sponsor, senior VPs and you, the project manager.

You distribute the project risk management qualitative risk assessment form to the three risk committees.  Since the team members are familiar with estimating probabilities and magnitudes, you use a 1-10 scale for the estimates.

Then you give the committee leaders their project risk management instructions, “Here’s what we’re going to do here. Each person will make an independent judgment about the probability of each of our risk events occurring and the impact on the project if they do. We’ll use a scale of 1 to 10 for each assessment. So if a risk event is very likely to occur, you should give it a 9 or even a 10.  For a risk event that is very unlikely, give it a score of 1 or 2. When you come to the impact decision, forget the probability of the risk event occurring. Simply assess how big an impact it will have. If its impact will bury the project and do us irreparable harm, you should score it a 10. If a risk event has minimal impact on the project, score it a 1 or 2.”

One team member asks, “Aren’t we going to discuss each risk first?”

You answer, “No, I think it’s best if each person gives their assessment without being influenced by the others. Remember that we have people whose immediate superior is on this committee.  If people share their opinions before we each score the risks, the managers’ opinion may count too heavily.  I want everyone to make their own judgment without knowing what the managers think. We may get better information with independent judgments and avoid some of the politics. For that same reason, we’ll keep the ballots anonymous. You’ll notice there is no place to fill in your name.”

A few days later, you tabulate the data from the completed forms into a spreadsheet designed for this purpose. The result is a table of data values and a graph for each committee. You take the risk management data and the recommendations from each committee to the risk management committee. That committee includes the sponsor and an executive vice president. You select one or two risks from each committee’s qualitative analysis and recommend conducting a quantitative analysis.

Because three of the risks have probabilities and impacts above eight, the committee decides that all three need quantitative analysis. They are particularly concerned about the risk of customers not using the new trouble report procedure. They ask you exactly what they will get from this quantitative analysis.

You say, “We will start with an influence diagram we developed during risk identification. Then we’ll gather some opinions from industry experts and build a decision network to analyze where we can have our biggest influence in avoiding that risk.”

As the quantitative analysis proceeds, you and the other members sketch out ideas for mitigating, avoiding or transferring these risk to other organizations. You will apply those strategies when the quantitative data is ready. You will have an expected value for each risk which will tell you the time and cost you can justify to avoid that risk. Risk Management Plan Presentation

Risk Management Summary

You can do a worthwhile risk analysis for a small project in a matter of minutes. You’ll invest more time and use more advanced techniques, like qualitative and quantitative risk analysis, for projects with greater scale and significance.

You can learn how to manage risks in our advanced project management courses. You’ll work privately and individually online with an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  Take a look at the course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” color=”red”]Consulting[/button]

Get free articles and videos like this every week

Project in Trouble

Is Your New Project In Trouble Already?

As project managers, we spend a lot of time and energy staying on top of the projects we’re responsible for.  project in troubleBut let’s say the boss hands you a project that’s already underway, one that you’re not familiar with and that has been managed by someone who is no longer “available” to discuss it with you.  How are you going to quickly assess the real status of that project and whether it is healthy or failing?  Here are a few quick tips about things to look for.  Enterprise Project Management Main Page

  • Stakeholder satisfaction.  Have the key stakeholders been kept informed about the project?  Do they know the status?  Do they feel like the project is on the right track?  Approaching just a few of the major stakeholders and getting some informal feedback may tell you all you need to know about whether the project is headed toward success or is on the road to ruin.   Stakeholder Analysis
  • Project documentation.  Does the project have a reasonable and adequate library of the key documents needed to properly design, resource, and manage a project?  The “library” will vary widely by the size and complexity of the project, so your assessment must be tailored accordingly.  But there should be an appropriate level of rigor about documenting project scope, schedule, WBS, budget, and key objectives.  A project plan, even a 1-pager, should be considered essential.  If it’s missing, there’s something wrong.  Project Plan
  • Roles and Responsibilities.  Failure to establish a clear definition of team roles and responsibilities is an invitation for team disintegration.  These should be clearly documented and unequivocal, and should be team “common knowledge.”  The first hint that disputed or misunderstood responsibilities/authority are afoot in the project should set off warning alarms.
  • Measures of success.  How does the project know if it is succeeding or not?  If there are project progress reports to review, are they meaningful?  Are there metrics that relate to project objectives?  If these questions do not produce quantifiable answers that address the customer’s requirements, then the project’s current track should be closely examined.
  • Documented requirements.  And speaking of requirements, if your initial review of the project’s documentation does not include some reference to specific, quantifiable requirements, the project is at serious risk of missing the target.  Without valid requirements, you’ll have no way to measure whether the project is succeeding or failing.  Requirements Management
  • Adequacy of the resources and staff.  Given what you can determine about the project scope and requirements, you’ll want to estimate whether your available resources are sufficient to meet the objectives and schedule—assuming there is one.  Is the staff sufficient in number and needed competencies to perform the work?  Are any physical resources you need available, such as lab support, test facilities, or specialized equipment?
  • Change control.  Don’t underestimate the importance of a rigorously followed change control process.  If it is clear that project changes occur without due process, you can quickly guess that the project is unlikely to stay on any sort of efficient course to achieve its primary objectives.  Change Control

There are other factors that you may also want to consider, such as team culture and morale, risk management process, external factors, etc., but if you keep the above factors in mind as you explore your “new” project you may give yourself a very timely opportunity to “right” the ship’s course before it hits the reef.

Project Charter

The project charter documents the project’s scope, objectives, resources, risks, assumptions, change control and the project manager’s authority. It should let the project manager identify problems and conflicts early so they can be resolved before the project work starts. It should help the project manager cope with the executive’s expectations about the project and how the PM will manage them. Project Phases Main Page

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

Project Charter: Common Problems

When problems arise mid-project, their impact is twice as severe as it would have been if you had dealt with them early.  The project charter is not just paperwork.  It’s a chance to avoid common problems that arise from the following:

  • Inadequate project manager authority
  • Misunderstandings about what the scope includes and doesn’t include
  • Unclear change control processes
  • Resources that don’t show up for project work
  • Risks that could have been prevented.

The project charter lays out the project’s high level scope, risks, constraints and resources.  It is the framework for the detailed planning and should be approved before planning begins. Right after the scope is defined and major deliverables are identified, the project manager has the sponsor’s and stakeholders’ attention.  It’s the best time to talk about what’s needed to produce the project’s deliverables. You have to be aware of the executives’ expectations, but they often don’t discuss them.

Bad Project Charter – What People Are Really Thinking

project charter

Let’s review a typical session where a project manager talks with an executive about the charter components. You’ll hear the words they say and then learn what they’re really thinking.

 Project Charter: PM Authority

Project Manager’s words: “I will need the authority to coordinate the activities of the entire project team and integrate their efforts so we can achieve outstanding results.  This authority must cross functional and departmental lines because the project does. I also need your support in securing resources, problem solving and change control processes.”

Project Manager’s thoughts: I don’t want a repeat of that last project where most of the team ignored their assignments.  I spent hours each week begging and pleading with them to get their tasks done. This project is bigger and I’ll need executive support when there are problems.

Project Executive’s words: “Of course, you have my full support. My door will always be open if you have any problems getting things done.  Now, exactly when are we going to finish and what will this cost?”

Project Executive’s thoughts: “Geez another project manager who wants to boss everyone around and have everyone in the company on the project team.”

Project Charter: Risks and Assumptions

Project Manager’s words: “I’m sure you’ve carefully read pages 46 to 77 of the project charter where I detailed the project’s risks. These are challenges that we must work together to resolve.”

Project Manager’s thoughts: I was up half the night thinking through everything that could possibly go wrong with this project and I think I got them all listed. So if any of those things happen, they can’t blame me. 

Project Executive’s words: “That’s a very careful assessment of the risks.  You certainly seem to have this project plan well thought out. I am in your corner.”

Project Executive’s thoughts: “Does this yahoo think this long list of excuses means that we won’t blame him? What a dope. If this project is late, the first thing I’ll do is end this clown’s career.”

Project Charter: Change Control

Project Manager’s words: “We need to freeze the project plan you’ve approved today.  We all know the devastating effect changes have on our ability to finish on time and within budget.”

Project Manager’s thoughts: These executives always want to add new stuff to the project whenever they wish. But they won’t change the due date and budget. That’s why we never finish on time and why no one’s ever happy with project results. That has to stop.

Project Executive’s’ words: Well, there is a need for flexibility but I certainly agree that we want to keep this project on course.” 

Project Executive’s thoughts: This is my project and I will add whatever I want to the plan. And this PM will salute every time I do.”

Project Charter Failure: No Problems Avoided or Expectations Changed

Here is a project that’s ripe for failure. The executive has negative expectations about the PM and their project management abilities. The project manager’s technique let the executive gloss over the problems instead of dealing with them. No one made difficult decisions or commitments.  The issues of the PM’s authority, risk management and change control were left to smolder; for now. Those smoldering embers will burst into flames in mid-project, when they will do the most harm.

There is a better way to present a charter. But it does not result in everyone leaving the meeting smiling and laughing. Why? Because problems and issues must be resolved now. Issues about borrowing people across functional lines, risks and making changes must be resolved before we start work.  Let’s see how a strong project charter does this.

Project Charter: Project Manager Authority & Resource Specifics

If you’re going to have problems getting resources when you need them, you must make an explicit request in the project charter. Don’t just ask for support. That means nothing. It’s best to find out now about issues with making assignments across departmental boundaries.  You should communicate about your project management authority in your project charter with words like this:

Project Manager’s words: “This project requires approximately  two hours a day from each of the following first-line supervisors during the month of June (List of specific names and titles).  As project manager, I will “own” those two hours every day.  During that time period, I’ll be able to directly assign work to those people from the approved project plan and schedule.”

Are those words likely to inflame existing issues about cross-functional or matrix authority? Yes they are and that’s the point.  By being very direct and crystal clear about the resources and the kind of authority you need to get the project done, you inflame the issues early. That gives you the opportunity to resolve them.  Now is the time to do it. You can link the resource issues to the project budget and completion date. Those things are currently at the front of the executives’ minds.  You can persuade them to approve your request by presenting the efficiency  and benefits of these requirements. You should state the delays and postponements that will result if we don’t get them.

Project Charter: Project Risks & Assumptions

You also throw gasoline on the project risk discussion by being direct about them.  Identifying every possible risk and assumption does not insulate you from blame. The fact that a PM listed 157 bad things that might happen in the project charter has never in the history of project management protected a PM from being blamed for a failed project.

Rather than list everything you can think of and have no one read it, you should identify 2-4 significant risks that will cause the project to fail. You present these risks in the project charter
with an estimate of the likelihood and magnitude of the impact.  You also offer at least one risk response for each.  Next you engage the executives in a discussion of the ways to mitigate the risks. This includes specific things they can do.  Then the executives can make a decision about what risks they want to run and what risks they want to try and mitigate. The project charter might identify a few risks like the following:

Project Manager’s words: “Ace Consulting has a long-term contract for engineering services based on charging hourly rates on a time and materials basis. They have many friends in the organization but they have a history of budget overruns and late finishes. This has happened on 16 of the 18 projects where we used them. Delays could cripple this project and cause us to finish months later than planned.  I would like the authority to issue a competitive bid on the engineering services.”

Once again, the direct approach in the project charter may seem a little pushy. However, it’s usually preferable to suffering problems with this “politically connected” vendor after they cause delays in the project.

Project Charter: Change Control Rules & Process

The last fire you want to inflame is change control.  Project managers who leave change control as an informal, casual process rarely have consistent success.  They and their team members are routinely caught between wanting a satisfied client/user and containing the scope of the project. The project charter must address this issue.

The cure is to set precise rules about who can approve what kind of changes to the project plan. The project charter might ask for project manager change control authority like this:

Project Manager’s words: “I recommend a rule that no change of budget, schedule or  deliverable can be made without my analysis of the impact on scope, cost, schedule, risk, quality and resources. And the changes must be  approved by an accountable executive.”

By being direct in the project charter, you can solve potential problems early

Project Charter Summary 

The project charter documents the project’s scope, objectives, resources, risks, assumptions, change control and the project manager’s authority. It is the framework for the detailed planning and should be approved by the sponsor before planning actually begins.

To learn more about implementing these project charter elements, consider our project management courses. You learn with an expert project manager as your coach. Take a look at the courses in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]