Posted tagged ‘Project Management’

Project Management Processes, Phases, and Personal Notes

October 10, 2008

One question I am asked often is how I manage my SharePoint projects, what stages I go through and how I perform/manage each phase of a project. This is probably something you already do, but perhaps it’s good to see some examples of how other people manage projects, so feel free to read along.

Personal Note:

This is a high level summary of what I do in a typical project and is not every individual item. SharePoint is also mentioned throughout this article because it is the technology I most often use when working on projects and organizing information.

Before the Project Starts

Before I start a project I create areas to capture knowledge (KB, and lessons learned), following that I begin the process of the project itself. This is important to do right at the start because even during the pre-project phases you can come up with some interesting notes, concepts, or lessons learned.

Right now I always do this knowledge capture using SharePoint with a mixture of wiki’s and related concepts. So this area is already built and all I need to do is create a ‘project’ and ensure the ‘customer’, ‘client’, and ‘area of business’ represented is also within the knowledge area to ensure anyone who comes up with something new can create articles, upload documents and basically create content that will be associated to that project, client, or business area.

Personal Note:

I normally break a project down into the following phases. Every project, regardless of the size. The good thing is that I do NOT enforce specific templates for each phase. I love the idea of templates in that they can save you time and certainly have some that I can make use of, but it’s important to not force yourself to fill out a document and certain content placeholders just because ‘its part of the template’. This can often create confusing statements, is a waste of effort, and really can detract from the important parts of the document.

Definition Phase

Domain Analysis

I always start off with some sort of domain analysis. That is analysis of the current environment, configuration, and system that is in place. How do things interact with one another? What applications already exist? What version are they? How are they used?

The results of this analysis will should contain an overview of the current servers, third party applications, shared service providers, configurations, and web applications, and existing site collections. I personally like to use excel documents for this (I know I could use SharePoint lists and may consider doing so in the future). Once these have been identified and cataloged the next phase of work can begin.

Requirements Analysis

Based on the objectives and target audience a series of business requirements must be retrieved. These requirements can come from business stakeholders, potential administration, and end users. It may be necessary to hold requirement gathering workshops with various involved parties in order to better understand how people would like to use the eventual system and how the system can provide them the most benefit.

Important things to note from personal experience during the requirements gathering phase:

  1. Involve every stakeholder in this requirements gathering. Even if it’s just to briefly talk about the requirements you have gathered from a high level. This will allow them to feel more involved in providing any input and requirements they might have and ensures that later when the system is being developed or implemented there are no significant surprises or missed requirements.
  2. Ensure you document the motivational reasons for a requirement as well as the requirement itself. This can really help you or the individual drafting the technical specification determine the correct solution for that individual requirement. This sounds simple but you would be surprised at how many people just document Requirements 1A-200C and forget to explain why these requirements even exist. This also can help you if later down the road someone says why did we do this?
  3. Prioritize the Requirements. Its important to identify ‘must have’, ‘would like to have’, and ‘if there’s time’ categorizations for every requirement. Its also a good idea to have further priority information. This extra priority information combined with the motivational reasons should make it clear where you need to spend most of your time, or make sure that the solution absolutely covers these areas.

Functional Specification

These requirements and the knowledge you have gained from the client now allows you to create what is often referred to as a functional specification. This outlines how the users expect to interact with the system, outlines their requirements and ensures that unanswered questions are resolved.

Some important points:

  1. Only one person should OWN (and write) the functional specification. This is very important. This ensures one person is responsible, one person can be referenced for information, and that the creative ideas and concepts represented (while based on many peoples input) is written and communicated by one individual. If the project is very large and this doesn’t seem feasible for one person break it into two smaller projects and have each person write their own specification for a part of it.
  2. Always have a developer or someone who will be writing the technical specification review your functional specification. This review should help point out gaps in the document, or knowledge so that you can interact with the client and retrieve answers without disrupting the technical specification process. (You don’t want the technical specification to start until the functional requirements have been hammered out if at all possible, that way you will not potentially need to redo some technical specification work if requirements change.)
  3. There should never be a question mark in the functional specification. Everything written in here will be signed off on and it should be complete. Ensure if you aren’t sure about something that it is classified as out of scope.
  4. The functional specification must not contain details on how it will be technically implemented. This is the kind of information that should be contained in the technical specification which is developed from the functional specification. The functional specification should contain a ‘from the user’ perspective.
  5. If possible provide scenarios. Scenarios are one of the easiest ways for any reader to understand something. It gives a real world example for how something works and can provide addition insight into why, and how it could be done.
  6. Make it READABLE. This one is very simple. If possible make it fun to read, or if that’s not possible ensure the language it is written in is to the point and easy to read. Never complicate it with business jargon or add extra adjectives to describe something just because you want to sound savvy or the document to seem ‘more professional’.
  7. Include a sort of ‘executive summary’ or overview that is short, to the point and describes high level what the functional specification outlines in more detail. This will allow those who don’t need to read the entire thing to still understand the information it contains.
  8. Include as much detail as possible. If you outline that there is a requirement for notification to be sent to a user make sure you write exactly what the notification will say, and identify any options or actions that can result from this notification.

Design and Architecture

Technical Specification and Architecture

Developer or Architect creates a technical specification or a ‘design doc’ as often I hear it being referred to as. Content contained in the technical specification can include how the solution will be built, what technologies will be used, what the server requirements and hardware requirements are, stuff like that.

Provide specific instructions for how things will work and if possible their dependencies. As an example if you know your end solution will most likely utilize a notification service that will require email provide this information in a clear manner so that upon sign off (or even before sign off) the analyst, consultant, or account manager assigned to interact with the client can begin getting you the things you eventually will need.

Graphic Specification, and Visual Design (or Screen Engineering)

With the technical specification complete we can now document how the screens, components, messages, and features will look to the end user. To be honest, I am not a graphic designer, or even really a designer. So my advice on this area is going to be limited in scope.

What I would recommend here are these few things:

  1. Make a specific note that these are recommended screen designs but that the end result may differ slightly. The initial screen designs rarely capture every single aspect of the solution and do not get modified at some point. They are the guideline and really help clients, developers, and anyone else involved understand what to expect. Since this is setting their expectations make certain they realize that minor adjustments may be necessary to make it more functional or user friendly down the road.
  2. Notify the client of any graphical changes. If you do make a graphical change or desire to make one after the client has signed off and the project has started in earnest, make certain you notify them. Get them involved even if it’s not an active role to make sure that it reduces potential trouble down the road.
  3. Do not add extra functionality to make things look nicer. Keep in mind you have a limited amount of time for this project. The designs should mirror what is outlined in the functional and technical specifications. Often (by accident) a graphic designer may adjust something to make it look nicer but not realize the implications that adjustment can have. It’s important to think about everything that might be effected by visual adjustments.
  4. Have technical staff review the design. Don’t just have the analyst, or consultant review the design make sure the developers also review it. They may point out inconsistencies or potentially better ways of presenting information or taking user input. They know the tools available to them, and in SharePoint as an example will know the effort required to style and adjust certain items, over others. (Example changing the way a list presents information as opposed to adjusting a master page.)

Development Plan, Communications Plan, Training Plan, Support Plan, Governance Plan, and Project Plan

Based on estimates for how long tasks should take and a logical rational breakdown of responsibilities create a project plan. I normally use Microsoft Project because it makes it easier to modify later, tell what’s on the critical path, manage resources across projects, and so on and so forth.

Important Note:Don’t forget your communication, training and support plans! These should be all elaborated on and clearly identified at this stage along with their time and associated cost. SLA agreements might be created here, or communication plans. So keep in mind that while I am only describing briefly the project plan and development plan that there are a great many other potentially required plans and agreements necessary before you should move beyond the planning stage.

Include clear identification of how the system will be governed in a governance plan. This is especially important for SharePoint deployments and is probably the single biggest thing I often see missed. Here is a TERRIFIC sample of a governance plan created by Joel Oleson and Mark Wagner: http://go.microsoft.com/fwlink/?linkid=92333&clcid=0x409

Create a development plan based off of the technical specification and the design specification. Ensure all estimates, times and tasks have been delegated under this plan.

Depending on the environment I like to use a RACI model for both plans.

RACI in this case stands for Responsible, Accountable, Consulted, and Informed. Basically for each developer/team member I make sure that it is clear whether they are responsible, accountable, need to be consulted, or need to be informed of each and every task. This is normally pretty easy to do, but it makes sure that everyone always knows who needs to be consulted with, informed of changes, or who is accountable for a task being complete etc.

Personal Note:

This doesn’t always make sense. There are some teams that may take offense to the concept, and it isn’t always the easiest thing to keep track of. However in important projects I believe this is an integral piece because without a RACI model implemented you cannot always determine what might have gone wrong, or how it can be resolved in the future. Personally I always use one and fill it out regardless, but it is best if each member has input and agrees to the RACI for each task.

One thing I also do is often use Project Server to really expand my capabilities in regards to being able to show the project plan, baselines, etc without actually requiring a user to download project. This is especially important because project can really be a scary big thing for most users upon first beginning to use it. It also saves lots of cost and some space on all the developer and related project personnel.

Specification and Project Plan Sign Offs

All stakeholders sign off on the functional, technical, and design specifications as well as the project plans. Everyone must be in agreement from the customers to the teams that will be implementing it. This saves time down the road, as it’s more costly to make changes to projects further into the project and ensures that all involved parties have been included and have taken responsibility for the solution.

Personal Note:

If there is trouble making the technical specification most of the time it is because the functional specification and requirements have not been fully identified. If the design specification has lots of trouble then it’s probably the functional or technical specification that might be at the root of these issues.

Development

The development phase is fairly straight forward. The technical specification has broken down the technical details. The design specification has broken down the look and feel. The development plan has broken down the tasks and responsibilities.

With all of those in place this is a smooth and easily managed phase of the project. It also has HIGH visibility of where things stand because you can always compare against the development plan, technical spec and visual designs.

Personal Note:

Standards are a wonderful thing but continue to evaluate them to ensure that they remain current, relevant, and useful. Keep things structured if possible as this helps you keep estimates more accurate. However do not crush your teams with impossible to meet standards. These provide no benefit and detract from the important of standards. Make sure all goals and standards are attainable and have clear indication of why they assist developers and team members.

Security Testing

One thing that I have seen over the past few years is a new more specific form of testing for security. In today’s world security is becoming more and more specialized and more and more important. To this end it might make sense to have a security team perform security tests, provide input on potential vulnerabilities, and often elaborate on ways to improve security for the code, application or system.

Unit Testing and QA Testing

There is unit testing and there is Quality Assurance testing. These are totally different things. In unit testing you will test individual components, and then STILL in unit testing you will test things integrated with one another often in a SIT environment. When all of this testing is completed and everything looks perfectly solid you move it to QA for testing. But only once you have fully tested the components.

QA will evaluate whether it matches the visual designs, and the functional specification. In some cases also the technical specification. Their job is more to just assure that the quality is there and come up with tests that the development team would not have thought of. Unexpected user inputs, or ways in which the user can use the system (still using the functional specification as a guideline) that maybe the development team missed.

Personal Note:

It is important to have a SIT (integrated testing area for all the individual modules and components) environment for development as well as a seperate QA environment. Keep in mind that all these environments should match as best as possible the client’s environment to avoid environmental issues and troubleshooting that might be needed down the road.

Deployment

Documentation

Before you deploy anything anywhere it should be clearly documented what you will do, what performance and outage’s it could result in, and how the changes you make can be undone.

Along with all of this you should also have any help documentation, user manuals, administrator manuals, and other documentation that is produced in your project complete or very clearly defined before implementing any solution on a client’s environment.

Lastly, document exactly what you do in that environment so that you can diagnose issues, or protect yourself from being blamed for unrelated issues.

UAT Testing

User Acceptance Testing is very important. This is where users review the solution in their own environment and ensure that their expectations have been met and that it is a usable beneficial system. Earlier in the plan it was important to note that any communication and training should be clearly identified. It is also important to note that if at all possible preliminary training at least should be done before UAT. This will ensure that your resources at UAT are not teaching people how to use the system as much as ensuring it meets or exceeds all of their expectations.

Personal Note:

For projects where the client doesn’t have the money or interest in training I normally expand the UAT cycle to account for the fact I (or my team) will also be training while performing the user testing.

UAT Fix and Testing Cycles

Taking any exceptions from UAT and ensuring that they are fixed and fully tested and then if needed ensure that the user has accepted the changes as well before moving on to the final deployment.

These cycles can often go back and forth more than once depending on how good communication with the client has been, how well client expectations have been managed, and how accurate the initial specifications and plans were.

Final Deployment

Your last deployment (aside from updates and new releases). This follows the same documentation rules as before.

Communication and Training

This is the full training, and communication phase. Often this could be workshops, webcasts, training sessions, assisting the organization with posters and improving internal user acceptance or user adoption etc etc.

Support and Feedback

SLA’s might contain what your support details are. Often this could be fixes, warrantees, upgrades, or even live support. It really depends on what you identified with the client. I also like to ensure that feedback is gained from the client. This provides a wonderful opportunity to create business references, case studies or other great marketing tools because the solution is new, exciting, and in (hopefully) most cases the client is very happy and satisfied.

Hope this helps someone or stirs some ideas for how to better manage your project through it’s phases,
Richard Harbridge

Advertisements

Beating Big Projects

July 30, 2008

Big Teams are Big Trouble

Your boss comes and gives you a (big fat) sizable undertaking. We all run into situations where you have to meet a deadline that does not allow you to accomplish the project with small project teams. So the first instinct is to add manpower to the project and increase the size of the project team to reduce the time it will take to complete the project. This is a very dangerous assumption and is a faulty one. I am not going to go into all of the details, but I will make a reference to the ‘Mythical Man Month’ which was presented by Frederick P. Brooks Jr. a long time ago. Basically the concept of the man month argument is that men (project members) and months (time) are interchangeable. Frederick P. Brooks Jr. explains that this is not indeed true. In fact adding men (project members) will almost always increase the months (time) it takes to complete a project.

The greater the size of the team the more intercommunication required, the more partitioning of work and delegation of tasks, and the harder it is to determine performance and status of the project.

So what do you do if it’s a large project? The worst way to approach it is to accept that it is a large project and as such will require a large team and so you just make the large enough that the time should be decreased. This is called the brute force approach where you shovel resources into the project in order to try and decrease the total time it will take to accomplish it. This always results in greater cost, more issues, and all sorts of concerns when it comes to upgrading and building upon the solution.

The simple answer or solution is that there should never be such a thing as a large project. That if the analysts, architects, and those who create the concepts of how the solution, or system will function do their jobs correctly the result will be either many small projects, or it will be broken down enough that separating aspects of the solution into individual projects should be possible. The truth is that difficult if not impossible deadlines always happen and that real world scenarios are rarely so simple.

For these special circumstances you create a manageable project team. That is a project team that is well within your abilities and that of your project management staff to manage effectively. This team will be your powerhouse that will do most of the work. To decrease the total time it takes to complete the project you add more resources. However, when you add these extra resources you make them supporting resources. They are extra satellite groups that provide support and assistance to the core project team.

This is not a new concept, Harlan Mills proposed it a long time ago, and I just think it’s always good to point it out from time to time. Harlan said that the most effective team for accomplishing large projects is one that is designed similarly to a surgeon’s team. Just scale his model out, and I believe it will result in the least costly and best end solution being completed. (This is my interpretation of his model, not his model word for word.)

  • The Surgeon
    The surgeon is the one who does most of the work; they have the education, training, and skills to do the best job, with the least amount of waste.
  • Co-Surgeon
    The co-surgeon thinks and evaluates the surgeons work. While often as skilled as the surgeon they often have less experience.
  • Administrator
    The administrator takes care of people, relationships, money and of course the necessary components. It’s the administrator’s job to ensure that the resources such as office space, staff, or objects that are required are provided and that everyone’s administrative needs are met.
  • Editor
    The editor takes care of documentation. While often the actual procedures, and work is completed by the surgeon, and much of the documentations important technical references are done by the surgeon the work of organizing that material and preparing it for others to read and understand.
  • Program Clerk
    The program clerk maintains records of the work completed, keeps up to date knowledge of the current status of the work being done and the technical properties of that work so that it can be interpreted and reused by both machinery and humans.
  • Secretary
    The secretary handles all project correspondence and primarily supports the administrator, editor and helps to co-ordinate communication for the support personnel.
  • Toolsmith
    The Toolsmith creates, maintains and upgrades the tools the surgeons will use. The toolsmith does not need to be directly included in the process of the ‘surgery’ but will be aware of the needs of the surgeon. Once the Toolsmith has defined a surgeon’s need they either find an existing tool for the surgeon that will satisfy the surgeons need, or create one for the surgeon. In a programming sense think of the Toolsmith as the person who creates the utilities that are made available to the Surgeon, but note that these utilities are more or less defined by the surgeon and his/her needs.
  • Tester
    The tester prepares test cases for the system as a whole (based off the functional specifications) as well as the day to day tests required for component testing and debugging.
  • Language Lawyer
    The language lawyer is your research staff. The individual who will optimize the work being done by find a neat and efficient way to do difficult, obscure, or tricky things. If there is a need he will also act as the individual who will find the relevant material and information to help improve a decision or aspect of the surgeons work.

While this concept was created to handle the management of information technology projects I believe it is universally applicable to all kinds of projects. The advantage of this system is that the surgeon (and often co-surgeon) need to understand the ‘surgery’ they will be doing, and why, or the project tasks and overall direction. But the support personnel should not need to know all the details resulting in a much greater conceptual integrity. (Limit the number of people who need to be responsible.)

So the secret to managing big projects that require (due to time constraints) a larger team is to use the surgeon approach as much as possible. That way you can keep your projects as healthy and happy as possible.

Hope this helps,
Richard Harbridge

Corporate Memory – The Good, The Bad, and The Ugly

July 29, 2008

Throughout the world more and more businesses (regardless of type, or size) are creating initiatives, are planning the implementation of, are implementing, or have implemented corporate memory management and support systems. Some names relating to Corporate Memory Management and Support systems are knowledge base, knowledge sharing, knowledge capturing, lessons learned, collaboration centers, and so on and so forth.

Why?

The goal of these systems is simple: “Promote an environment that captures and shares the knowledge and experience gained by individuals, and collective groups to the organization as a whole in an organized manner so that everyone can benefit from the progress, work, and lessons learned generated on a daily basis.”

The benefits of something like that are obvious, novices can gain the insight and experience of veteran staff, new staff can find all the resources they need, the cost to manage, transfer knowledge, and train staff decreases while the capabilities of each staff member increases and as a result so will customer satisfaction.

How?

The most common answer I hear to this is “by applying technology”. While I wish it was this easy, I assure you there is a very large amount more than just technology involved in providing a good Corporate Memory solution for any company. The technology is often an important tool that can be used to improve a corporate memory solution, but the reality is that the actual corporate memory solution can always be done, with or without technology.

This isn’t a new concept, companies have been doing it for a very long time, and those who have done it well have become exceedingly successful as a result.

The best way to create a corporate memory solution for your organization is rather simple. Just follow the few steps I outline below and you will have a much greater chance than if you missed one of these crucial items.

1. Don’t rely on technology to solve your problems.

You see this happen all the time. People hear about a content management (or document management), and collaboration system and often believe that by implementing this system you will have the automatic collection and sharing of all corporate data.

The truth is that the business processes, data to be collected, the communication and training, and the overall user acceptance of the system all play a far greater role than the technology does in a corporate memory management solution. The technology just supports these other areas that must be clearly defined, planned, and implemented in order to have a good corporate memory solution.

2. Information requires context to become knowledge.

This is important. Information is not knowledge. Information alone is unusable as corporate memory without context. The context provides a way for everyone to relate the information to something they can use. It’s the relationships to business processes, and metadata (related information) such as purpose, and how it can be applied that makes the information become knowledge that is usable by the individual, or organization.


So to implement a corporate memory solution for your organization you have to figure out what all of those business processes, purposes, and metadata will be. Don’t worry you don’t need to know all of it, just everything around the first information expected in the system and a plan to ensure that as more information comes in you will be able to keep up with that information’s context to ensure it becomes knowledge, and doesn’t remain information and just ‘clutters the shelf’.

3. Knowledge requires maintenance.

Many people forget that knowledge requires maintenance. It has to be constantly evaluated to see if it is still relevant, to ensure that the relationships and metadata are still appropriate and that they still provide a purpose and application in the business. Knowledge that isn’t well maintained falls into disarray, it becomes outdated, it degrades belief in the corporate memory solution as a whole, and most importantly it becomes unusable to the individual and organization. Without maintenance it becomes information with a pretty dress (and unlike fashion these outdated clothes don’t come back into style – zing!).

So make certain you have a good maintenance plan, and not just the technology, I am talking about communication, training, and of course the constant evaluation and analysis of corporate memory.

4. Corporate memory is organic.

Some people often think of corporate memory as data. Which in many ways it is, but the key is that it is organic data, which grows and changes overtime. This is a wonderful beautiful thing. What it means is that while your business grows, evolves, and changes the knowledge contained in corporate memory will grow, evolve and change with it.

What this means is that your corporate memory solution must be able to grow, evolve and change along with the corporate memory and your business. Things like a good maintenance plan (that is constantly evaluated) and a good framework for managing information context are integral to the success of a corporate memory solution.

5. You do not harvest knowledge, mine it, or fish for it.

Knowledge capturing and understanding that knowledge’s context cannot be achieved by harvesting, mining, or fishing. You can’t just harvest documents, mine them for the information you think is important and guess what contexts that knowledge can be used for. If you do that all you end up with is information. This as I mentioned earlier is unusable in a corporate memory solution.

Instead you need to create (forgive the bad analogy) the fertile field in which knowledge can grow and plant the seeds. Remember that knowledge is organic, and that initially while you set up the plan, framework and solution that it will change overtime and that it is impossible to guess how the knowledge will grow. This planning and hard work to create a solution is the field in my analogy. And the seeds are the first pilots, communication methods, and training aspects that you implement to get your corporate memory solution to grow (in the direction you want it to).

If you try and harvest, mine, or fish for the knowledge you will just end up with barren fields that don’t bear fruit. (Last one, I promise.)

If you carefully think about those points I am confident you will implement a corporate memory solution that will not only provide wonderful opportunity, growth and power to your organization and its members, but you will also have done it in such a way that you don’t have to redo all of the work a short time down the road just because the technology changes (which it always will).

Thank you and best of luck to your corporate memory solutions,
Richard Harbridge

Schedule and Keep Track of Everything

July 22, 2008

The only way you can estimate, consider, and implicate cost is if scheduling is maintained and accomplished correctly. You cannot decide whether one feature is more cost effective than another unless you can know how long each will take.

Here are a few simple benefits to documenting everything, both personal and business related:

  1. Future estimates are more accurate in both personal and professional areas.
    This can help you ensure you have more time, don’t have to work overtime, and overall remain more satisfied and successful (both perceived and actual)
  2. You can keep a timeline of your professional and personal achievements.
    Great for performance reviews, job interviews, career building, and personal satisfaction.
  3. You can provide better assessments of where you are on something.
    When someone asks you how is this coming along? You can say honestly and relatively accurately that you are about half way there. Providing real quantitative status indication rather than a “alright” answer.
  4. Find mistakes sooner, and avoid repeating the same ones.
    Since you are documenting your lessons learned you avoid making the same mistakes, can solve issues faster using experience that you can review at any point in time. Often when documenting something you might discover something you missed or spot a mistake before it happens, providing you time to either resolve the issue, figure out a solution/workaround for it, or (I hate to say it) prepare an adequate excuse for the issue.

So why doesn’t everyone do project scheduling, break down tasks, and document everything?

There is this general idea that it will take longer for many small projects to whip up a schedule than it would to just do it. This is never true. In fact I would argue that even the smallest of projects estimated from a high level of a few hours should still be scheduled. That way you can keep TRACK and see the actual cost of whatever projects you do. If you don’t you will have no way of proving or bringing visibility to the work you did.

If you do not record the time spent on a project and outline what the project represented it gets hard to tell your boss, co-workers, relatives, interviewer for that snazzy new job, or nagging wife what you have been doing all week, all month, or even for the past year.

Even when I do small tasks I write them down, and categorize them. So at any point in time I can tell anyone who is interested exactly what I have been working on, and (since I put these into SharePoint lists, outlook, excel documents, or ms project) I am able to generate reports on how much time I spend on IT tasks, QA support, analysis, or other important areas.

Don’t forget to highlight interesting, or important things you did.

This does more than just allow you to report how much work you do, why you might not have been able to hit a deadline, why you are working so much overtime, or why the amount of hair on your desk is greater than that on your head; It also provides you with a real way to measure your own progress. This way you can tell if you are actually doing the things you like, see where your strengths lie, and provide real proof to management that your doing work either out of your job description (which means you deserve a raise) or that you would be better suited to a specific type of work.

The best part is that you will have a listing of tons of things you have done for the company you work for. When performance reviews come up, or that better job posting appears wouldn’t you like to be able to just take a report and give it to your boss or interviewer and say these are the ways I have improved the company I work(ed) for.

Think about it,
Richard