Project Management – the next generation

Myth: Only large companies can afford PM software
A couple of years ago it was only the large industries that could afford Project Management Software. That has now changed. Small and Medium size (SME) Enterprises can now also afford to get onboard.

These larger industries had to invest hugely in server farms, server licenses and then still pay for each of their employees to use software.
The trend shifted to cloud based solutions a couple of years ago, but the change did not stop there.
The Microsoft’s of the world are now hosting their own solutions which makes it cost effective to use and you no longer need to have strong infrastructure at your offices in order to run project management solutions. Environments are almost instantaneously provisioned which means there’s no need for infrastructure projects to get you going. The most beneficial part of this is for an SME is that you don’t really need an implementation partner, unless you want to configure the environment to suit your business needs. If you are happy using it as is until you’ve figured out how to configure it yourself, you will save tons of money.

Myth: Technology are not important
Technology shifts require quick adoption and projects can hardly be planned on the back of a cigarette box anymore. Project managers of today needs to be proficient in using technology and youngsters can’t anymore be the only once taking advantage of it. The need for collaboration will force the old school to stay with-it.
The demand to manage portfolios, instead of just managing stand-alone projects is also on the rise and technology has finally started catching up. Third party service providers should for the foreseeable future still form part of this booming industry.

Myth: Methodologies should stay put
Let’s have a look at methodologies. In the rat race world we live in, bulky methodologies will not make the cut if you need your business to stay agile. Documenting for the sake of having documentation can be seen as wastage and only the most critical processes needs to be on black-and-white.
I know that in certain cases it is required that every step of every process need to be followed to the T to ensure proven governance, but in other cases companies need to adapt or die.

Myth: Anyone can manage a project team
Although project management skills can be acquired quite easily, a couple of more difficult skills are needed to effectively manage a project team. Google will tell you that there are a lot of additional skills that the next generation project managers need to possess, but these are the ones that I feel are important:

1. Emotional Intelligence: screaming, shouting and cursing your team will not motivate all of them to deliver on time, on budget, within scope and to the set quality. Without emotional intelligence you cannot build successful stakeholder relationships, deal with difficult team members, manage conflict or avoid emotional breakdowns.
2. Collaborative Communication: The ability to adapt the way you communicate to suit the audience in a matter that brings collaboration to the table. Communication stretches further than just speaking. Because social media continues to be on the rise, the profession will in future rely less on direct face-to-face meetings. As a project manager you need to hold skills to effectively lead phone meetings/conference calls. As companies grow, these interactions will also stretch to other countries which brings about dealing with other cultures, languages and mannerisms.
3. Flexibility: The disposition and ability to change one’s tactics/methods in response to business needs.
4. Business Understanding: Knowledge of the company’s business, strategy and wider industry. Ability to comprehend the strategy of the company and ensure alignment in the execution of projects.
5. Analytical Skills: The ability to analyze stumbling blocks and find appropriate ways for dealing with it.

Project management went from a role to competency within companies, but in my opinion we should still see a major shift. This shift should be not only in the maturity of project managers, the way they conduct their profession on a day-to-day basis, but also in every single function they fulfil.


Project Governance

Definition: “Project governance is the management framework within which project decisions are made.”

Other definitions define it as: Project governance is a framework that sets out the structure, resources, communication, reporting and monitoring systems to manage a project consistent with an organization’s corporate or strategic vision.

It is there to guide the way for project management in an organization.

You will find blogs on the internet by authors that seem to confuse workflows with project governance. Herewith how I see it:

Project governance guidelines
In my mind, the following guidelines are crucial to good project governance:

1. Accountability
A single point of accountability is critical to the success of a project. In most organizations the Project Manager will assume responsibility for the project whilst the accountability will rest with either a Programme Manager/Project Office Manager/Project Director.
Without clear leadership and accountability, issues may arise that will affect all projects at some point. If there is not a person in place that will lead the project it may also cause delays since there is no single point of decision making.

2. Project ownership
The Project Sponsor is often seen as the owner of a project. This sponsor could be a senior executive in the organization or may even be a director. The main purpose of this role is to provide certainty that the project will meet the objectives, which is critical to project success.
This person should also ensure that value for money is gained and that the agreed scope of the project is adhered to. It is also imperative to ensure internal projects maintain alignment with organizational strategy. In the services industry projects needs to be overseen from a high-level and intervened when necessary.

3. Decision making
The larger the group of decision makers, the longer it will take to reach consensus. In the project management space, the turnaround time on decisions needs to be quick, but obviously not hurried.
What is important to note here is that people with sufficient decision making abilities should form part of the project team as project-level decisions should ideally not wait for a board meeting to take place. Decisions could be recorded in a decision register, preferably on the project management system and then routed for approval electronically if the next progress meeting is too far away.

4. Roles and Responsibilities
The roles, responsibilities and performance criteria for the governance of project management needs to be clearly defined. These can for instance be maintained in a project management pack or even reside within the project management plan.

5. Project Approval
All projects consist of an approved project plan, containing numerous approved documents. This could either be electronically approved via a document workflow or be a physical signed off document. It is in my opinion of utmost importance these documents are stored on either a project site or repository for easy access by project team members.
Should there be any changes to the project like scope or timelines, this also needs to be approved by the relevant stakeholders.

6. Trust
There needs to sufficient trust between project team members to ensure that communication around issues are appropriately disclosed and managed internally.

Nitty-gritties of governance and where technology can assist

Project governance may include, depending on the company, at a minimum the following:
* A well-written Statement of Work (SOW) (or Sales Proposal depending on the type of company), stating the objectives of the project, deliverables and timelines/pricing. Technology will unfortunately not assist in writing the SOW.
* A Purchase Order from the client that is centrally stored
* Identification all project stakeholders by using Build Team functionality
* A signed-off Project Charter documenting what is in and out of scope
* A signed-off Requirements Document
* A project schedule that spans all project stages from project initiation through project closure encompassing the development lifecycle
* Appropriate amount and level of resources are assigned to the project (could be a request to a resource manager that is workflow-controlled)
* A project management system, ie. Project Server 2013 where the project schedule resides to allow for optimal assignment of resources and project tracking
* A central document repository or project site or even a project file is there is not system in place
* Procedures on how to manage scope
* Project decisions are documented in a list item on a SharePoint site
* In using a project management solution like Project Server, it will allow project team members to raise issues and risks that arise during the project. These issues and risks can be managed centrally and can roll-up to a portfolio level for ease of reporting back to management.
* Workflow, to assist the organization in ensuring each and every stage within a phase and ultimately the project lifecycle, will be adhered to.
14. Project closure meeting to assess the compliance of the completed project to its original objectives as well as to document lessons learnt.

There are also other stuff that can be seen as fundamentals like a communication plan.

Project governance should not be seen as a whipping stick, but instead as an operating framework that is proven and repeatable.

Importance of decision registers

How many times have you seen projects go south because decisions or actions weren’t properly documented or approved?

As per the blame game, the project manager will have to bear the crux for not ensuring proof of decisions or why certain actions were executed.  So exactly how do you cover yourself?

Now, I’m not saying go wild and have your project sponsor and stakeholders sign off on every little decision, but it is of extreme importance that some register be kept up to date throughout the lifecycle of the project.

Should a project manager neglect to do that, well there is your first input into a lessons learnt register as well.  Jokes aside, I firmly believe that as input into the project closure report, you need to list all major decisions reached during the duration of the project.

Alternatively, you can spend a week to do a proper close-out report by sifting through every single e-mail ever sent to or from any stakeholder or team member.

I’ve learned this hard lesson on a disastrous project where the client project manager insisted that no changes could be seen as out of scope seeing that the sales person promised it during the sales cycle.  Of course, by that time the sales person was long gone, no proof existed of what was promised to this client and what not.

It literally took me a week to do a proper close-out report.  Yes, we documented most of the happenings during the project, but without having proof of decisions taken even before the project starts, is a big no-no.

I’ve seen clients contacting team members on a project directly, bypassing the project manager completely.  Guess who looks like the fool?  Not the resource, not the client, but the project manager.  Resources being the good guys they normally are and bending over backwards for the client, implement small changes on the client’s demand without realising the bigger impact on the project timelines and costs.

Team members needs to be trained on the project methodology as I’ve mentioned before in other posts on my blog.  In this specific example, these resources should either have referred the client to the project manager as the primary contact, or captured it on the action register so the project manager is at least aware of it.

Minute it?!

Some project managers prefer capturing actions or minutes in meeting minutes, which means you will have to constantly refer back to numerous documents.  Not a bad practise if you have loads of time on hand, but when you’re running multiple projects, I believe having it on the project site as a list item or content type might just make your life a little bit easier.

The most important things that need to be captured are:

  • Date the decision was taken
  • Description of what was agreed
  • Reason for the decision
  • Approved by
  • Status, ie. Approved, pending, rejected, cancelled
  • Should Steering Committee approval be required, I would personally capture details around the meeting like when t was held, again, what was discussed during the meeting etc.
  • If it was captured on a list item, you will also have the ability to link documents to it


Reporting on decisions

Just having captured the information is a great start, but you actually need to do something about it.  I like to incorporate decisions and actions into progress reports as opposed to the meeting minute option.  That way, stakeholders are more likely to actually review it.  We all know how meeting minutes gets ignored until just before the next meeting is held.  By using Project Server, capturing these decisions on the project site will allow you to create an SSRS report that incorporates this type of information.  Why not also create a report showing all decisions taken across projects?  That way, if a similar type of project is conducted, you will know upfront what type of decisions would need to be made during the project.


Project Charter

Another option is to capture decisions taken in the Project Charter which is mostly seen as a living document that gets updated regularly.  Call me crazy, but I’m not too fond of constantly updating documents and sending it out for approval.  I would much rather sign-off the charter in the beginning of the project and keep the decision and/or action register separately.

Similarities between Operations and Project Management

 Now you might say this is coming from someone that has lived and breathed project management over the last decade.  That is true.  You might even say that crazy is going around a bit too many these days.  Nonetheless, let’s think about it.

My good friend Wikipedia suggested that Operational planning is the process of linking strategic goals and objectives to tactical goals and objectives. It describes milestones, conditions for success and explains how, or what portion of, a strategic plan will be put into operation during a given operational period, in the case of commercial application, a fiscal year or another given budgetary term.

If we think project management – it is commonly known as the discipline of planning, organizing, motivating, and controlling resources to achieve specific goals.  You then have all your different knowledge areas:

Project integration management.

This area coordinates and applies the work of all of the processes so that they integrate all flow in a coordinated and smooth manner.  

It consists of:

  • Develop Project Charter
  • Develop Project Management Plan
  • Direct and Manage Project Execution
  • Monitor and Control Project Work
  • Perform Integrated Change Control
  • Close Project or Phase

If you are using project management techniques to operationalize your business you can include the following:

In an IT-context you can run your system implementation as a project.  Why not include the maintenance/SLA work afterwards to have a total picture of work done for a specific client?

In a mining context productivity is always a focal point and investment is normally directed toward expanding production capacity.  Why not capture your daily diaries in an electronic format which feeds into the project management system?  If your operations are integrated, why not share costs, research and development across the board?

Project scope management.

Project scope management is vital because it ensures that the project includes all the work that is required to complete the project successfully.  Any additional work that was not included in the original scope statement can be seen as scope creep.

Operations:  You sometimes need to reign in excited employees that can easily take set daily operational work to the next level – they are better known as cowboys.  The scope of day-to-day activities can be managed by running operational projects and controlling the work on your project management system.

Project time management.

This is concerned with the resources, activities, duration and scheduling so that the project manager can control the timely completion of the project.

If you think operations, let’s list what is normally included:

  1. Forecasting
  2. Capacity Planning
  3. Scheduling
  4. Where are we now?
  5. Where do we want to be?
  6. How do we get there?
  7. How do we measure our progress?

Schedules can be setup for repetitive type of work to budget and ensure work is delivered on time.  If you’re using a scheduling tool, it will be so much easier than using old fashioned spread sheets.  Not only will resources be notified of tasks assigned to them, they will have a platform to potentially see what work other people are working on.  They will also be informed enough to plan their daily activities.

If we look a bit wider – a resource manager in a banking environment should be able to know exactly who’s doing what when.  The same goes for pretty much any other type of environment.

Project cost management.

Project cost management consists of estimating, budgeting, and controlling costs to ensure that the work can be completed within the approved project budget.

The above can be said for operations as well.  If you schedule all operational work in your project management system, each resource should have a rate associated to their skill.  This, together with any fixed costs that needs to be incurred on any type of operational project, should roll up to the company budget for the financial year.  Schedule in the purchase of a new server, replacement of aircons in a server room etc and match it up to the ops budget.

Project quality management.

This knowledge area covers the planning of quality, and the performing of both quality assurance and quality control.  If you’re writing a piece of software it will go through all the different types of software testing to ensure the right quality is met.

Normal operational quality management can pose questions like:

  1. Is your equipment maintenance policies correct?
  2. Is your quality control done too late during the production process?
  3. In your restaurant are all food cooked at the correct temperature?
  4. Do you regularly conduct air quality assessments on your mining operations?
  5. Was your product produced correctly?

From an operational perspective you can go a bit further:

  1. Are processes performing effectively?
  2. What criteria should be met?
  3. Are the criteria being met?
  4. Are you training your resources to cross-function?

Does your quality management system aim to bind the work and material resources of your organization in the most effective way to achieve the objectives of the organization?

Project human resource management.

The project manager must be a good leader and be able to motivate and influence the team to be successful. In addition this knowledge area focuses on the team management tools as well as the interpersonal skills.  On a project you will develop you resource plan, acquire the team and then develop and manage them.

Again, operational management works quite the same.  If there is a job opening, you will develop the job description for the type of resource you need.  You then need to acquire the skill in the market.  Once you have appointed a suitable candidate you need to ensure their skills are developed and they need to be managed by the team lead/manager.

If you’re using a project management system that can show you the workload/demand on resources as well as the actuals worked it will put the power back in management’s hands.

Project communications management.

This knowledge area focuses on keeping the stakeholders appropriately informed throughout the life cycle of a project. It includes the processes that ensure timely and appropriate generation, gathering, circulation, storage, recovery, and the ultimate disposition of project information.

Again, the similarities are striking.

During your normal operations you need to also give feedback to staff, executive management, the board of directors and most importantly clients.  You need to ensure that you have the right management information at hand to provide all types of feedback and not base it on thumb sucked stats. Daily stand up team meetings are great for ensuring communication flows and are a good platform for discussing and resolving hampering factors.  This can be built up to include management to align regularly (even just for 15 min per day).

Project risk management.

Project risk management is the identification, assessment, and ranking of risks followed by the methods resources are applied to decrease, monitor, and control the probability and/or impact of events that might occur.

The term Operational Risk Management is defined as a continual cyclic process which includes risk assessment, risk decision making, and implementation of risk controls, which results in acceptance, mitigation, or avoidance of risk.

There is no real difference between project and operational risk management in my mind.  So why not use the same system you use for project risk identification and run it for your business?

Project procurement management.

This PMBOK knowledge area is used to obtain goods, services or scope from outside the organization.  It might or might not be handled on the basis of formal procurement activities.

If you are operating a manufacturing plant you surely need to first plan what needs to be procured, conduct and administer and lastly close the procurement loop.  This might sound like a repetitive process that doesn’t need to be tracked, but how else do you ensure that everything is happening?    How can you improve on your procurement if you do not know how long it takes from beginning to end?


Bringing it all together

If you consider all of the information mentioned, is there any reason why your life of mine cannot be scheduled as a project?  Why can all work happening on your manufacturing plant not be scheduled as small iterative projects rolling up to achieve the strategic goals set out for the company?

The search continues for technologies and processes that raise productivity while at the same time ensuring costs and risks are managed……  I am saying – why not use your project management tools and techniques to do just that?

Portfolio Prioritization and Selection

I have found that the words “Portfolio Management” are used by most companies, but not used in the sense that it should be.

Definition:  A portfolio is a collection of projects and/or programs and other work that are grouped together to facilitate the effective management of that work to meet strategic business objectives.

The above mentioned projects or programs may be related to each other or it may not.  The work set out however, should be directly related to the organizations strategic drivers.

It can also be seen as the central management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs, and other related work to achieve strategic business objectives

How do most companies prioritize?

I’ve come across companies that list possible initiatives on spread sheets and go through rounds and rounds of elimination to meet the targeted budget.  These eliminations are not conducted by executives, but by PMO members.  Should this be allowed?

In addition, the projects get eliminated on the basis of not meeting the organizations goals, objectives and drivers, but on the basis of “we cannot afford it right now”.

Even though that is not an incorrect basis to start off with, what about legislative projects?

Do you even have enough resources to execute the current pipeline?  Is the appropriate governance set?  Do you prioritize according to the level of risk introduced by not executing certain projects?

In order to do proper portfolio management – projects, programs and operational work/stay in business projects within the portfolio should be prioritized and chosen objectively and not by the act of the executive that screams the loudest.

What level of input is needed before the process can start?

Is the list of initiatives collected from different business units enough to make decisions on or should more information be taken into account?

If you have a closer look at the questions posed above, it will indicate exactly what needs to be taken into account whilst prioritizing:

  1. Strategic Goals:  each initiative in the pipeline should be measured according to the company’s drivers.  Once all the initiatives have been independently assessed and measured, you will be in a position to look at the overall pipeline of projects.  Examples of strategic drivers may include increasing market share, improved product quality and enhanced visibility to name a few.  Each driver should be associated with quantifiable impact statements.  Both the driver and the impact statements should be specific and measurable.  Once all the drivers have been set up, it should be weighed against the other drivers.
  2. Resource Planning:  By assigning generic resources to all the initiatives, it will allow the portfolio managers to see if the current resources, whether material, cost or work resources are enough to execute or if more resources should be acquired.
  3. Risk:  the level of risk of not implementing some projects might be higher than the risk introduced by executing these.  In my opinion risk is an extremely important portion of portfolio prioritization and selection.
  4. Budget:  do you have the finances available to execute the full pipeline?
  5. The selection of initiatives should also take into account similarities and inter-dependencies for mutual inclusion or exclusion.

Portfolio Reporting and Review

In my view, selection can only be done after all the initiatives have been reviewed more than once.  Does you spread sheet allow you for dynamic reporting during these reviews?  If you’re using a portfolio management system the typical reporting may be strategic alignment and scatter charts.  If you are prioritizing according to resource requirements, a hired resource report will highlight if you have enough resources to execute the pipeline and if not, where the shortfalls are.

The selection exercise may expose major differences of opinion amongst the key stakeholders/executives. No tool can make the decisions for you as it is only there to assist with the decision making process.  Consensus on the chosen portfolio is of extreme importance as this is what will make or break the projects and /or programs down the line.

What happens to rejected items?

The portfolio management system used should allow for “parking” rejected items and revisiting them in the next budgeting cycle.  If it is completely rejected, you should be able to provide explanations when asked and notify the initiator of that item.

Portfolio Selection in the Services Industry

In theory, portfolio selection can work great for normal companies, but it will always be more difficult for companies in the services industry.  You need services to survive and the question needs to be asked if you can afford to turn down work.  In my opinion, the most important selection criteria in the services industry will be based on resource availability and risk profile.  Risk profiling is vital if you’ve delivered for a specific client before and the interaction was not as intended.  The question should then be asked if your appetite for risk is so great that you will risk your reputation by implementing another project for the specific client.

Once you have selected the portfolio that you want to execute, managing and controlling the portfolio to realize the business drivers can start.

Is your portfolio management tool failing you or are you failing the system?

Reasons for Projects Failure

We’ve had a handful of projects that failed over the last year and a half. Thinking back and reflecting on what went wrong on them, I came up with the following possible reasons that could cause failure from the sales cycle through to project close-out (excluding Monitoring & Control):

My # 1 Reason: Incorrectly Sold
There are so many eager beaver sales guys out there, that they’d promise a potential client the world to get the deal in. What is wrong with this? Months and months down the line – the service provider is still stuck with the same project because the “Yes” Man/Sales Guy told them the system can do so and so, but it has never been quoted for. Sounds familiar? This could potentially be a doubled edged sword as the client could be taking chances.

Solution: In my opinion a technical person needs to attend sales meetings with the Sales Guy in order to ensure that nothing is over promised.

# 2: The wrong solution was sold
This one is unfortunately also due to the “Yes” Man (or sales executive). It is not necessarily my second reason for failure, but more a case of what goes wrong before it even becomes a project. The client asked for X. The sales man bastardised the client’s high-level requirements to a solution that is not suitable. What happens here? The poor developers and consultants needs to slap a poorly designed system together.

# 3: Bad Estimation during the Sales Cycle
Now I know you’d think that estimation should happen during the Project Planning Phase of the project, but the first part happens during the sales cycle in the Services Industry. It is easy to sell the client a boxed solution – you can easily determine the amount of effort it will take to complete the job.
Custom development – now there’s a beast of a different nature. How long is a piece of string? The developers that need to assist Mr Sales Guy here are normally too busy on projects that were incorrectly sold and can’t focus properly on providing estimates that needs to go into the sales proposal. So, even before it becomes a project, it is doomed for failure.

#4: Project Commissioning Gone Wrong
So the project was sold either correctly and incorrectly, but no handover was done from the Sales Guy to the Project Team during the Project Initiation Phase.

Solution: The Sales Guy needs to schedule a sales handover meeting with the Project Team to bring them up to speed on what was sold. After the meeting is conducted, the Sales Guy needs to go with the Project Manager/Team to the client for the kick-off meeting. During this kick-off meeting, the sales solution needs to be discussed with the client and high-level deliverables (if not added to the sales proposal) needs to be defined.

#5: Poor Planning
I know Project Managers are usually to blame here – but are they really? Should planning not be a collective effort by the Project Team?

#6: Scope Creep
There are two possible reasons here: Either the scope of the project was not clearly established during initiation and planning or the project manager failed to manage scope change requests effectively. You get those projects that run smoothly due to the articulation of the requirements by the client and then you can sometimes get the out of control ones.
Scope changes, even though sometimes painful, are not necessarily a bad thing for the services industry as it means more money coming into the company.

Solution: now this is just logical (to me at least) – as long as scope changes are properly documented and signed-off by the client, then managed and executed – everything should go well. In my opinion (and I’ve mentioned it in previous blogs), project teams needs to be properly trained on both the project and development methodology. You might ask why a normal team member needs to be trained on the Project Management Framework and the answer is this: If your team does not know what the scope of the project is (especially young, fresh out of varsity guys) and they do not know how scope creep it will affect the project, the PM has got his work cut out for him. More importantly – the team needs to know what has been defined as out of scope in the Project Management Plan/Scope Document.

# 7: Project Staff Turnover
If a project team member resigns knowledge gets taken away from the project. This will put the project at risk as the new team member may need to revisit/investigate past decisions made. Even if a team member doesn’t resign, but is allocated to a new project, this poses risk. Another risk here is placing an employee for too long at a client site, as the client might end up poaching your staff.

Solution: Have planned rotation of employees in place for contract placements. Ensure that project decisions are documented. Ensure all client communications are stored on the project site/document repository.

#8: Bullies
This isn’t about someone physically or emotionally bullying someone else. This has more to do with egos and titles getting in the way of work happening. The employee attitude of “I’m too important to be doing menial tasks” could have a huge impact on project deliverables, not to mention the influence of this individual over junior team members.

Nirvana: highly evolved individuals/project teams should have no problem reporting to someone (the PM) that is not on their salary bracket/level in the company. If the team members are committed to the end goal and know that a project is only a temporary endeavour, it is a good starting point. Most importantly, in my opinion, there should be no place for egos on a project.

#9: Communication
I’m not talking here about communication to the client. I’m also not talking about the communications plan. The Project Manager can only communicate progress to the client if there is adequate communication amongst the project team. If the team does not play well together or prefer to work in silos, there are problems waiting to happen.

Solution: Ideally, a profile matrix should be drawn up of all company employees and personalities that complement each other should be matched up on project teams. It might sound a bit ridiculous and far-fetched, but it will alleviate a lot of stress for the Project Manager and HOD’s.

Walking Away from a Project Gone Bad
Calling a halt to a project that is underway is not a stress-free thing to do, but do you really want to continue working on a project that will not be bringing in any money? It is extremely important to maintain neutral and stay clear from the disillusionment related to sunken costs that may overcome you. Before the project can be cancelled it is important to meet with internal project sponsor (when working in the consulting industry) and review the costs-benefit analysis of the project and additional opportunity costs that will be lost should the project continue.

I know there are a lot more reasons why projects fail, but these are the ones I’ve had to deal with recently.

Local Microsoft Partner Awards

Herewith some pics of our WINNING team and awesome new CEO:


Herewith the amount of awards we’ve won:


It is absolutely unbelievable that a company can win 3 Local (Project and Portfolio Management, ISV, Spark) and 1 International Award (B2B Mobile Applications) in the first year of existence!  The glory goes to GREAT teamwork and not just one individual person.

Go FOXit!!!