Skip to main content

Tag: Best Practices

10 Key Success Factors for Application Implementation Projects

Written by Brenda Hallman on . Posted in Articles. 88 Comments on 10 Key Success Factors for Application Implementation Projects

There are many factors in an application implementation-related project that over time have proved to be key contributors to the success of such projects.  This includes items that may seem obvious, such as solid testing, communication, and involvement by key staff members, but these are often under utilized in favor of saving time.  When projects skimp on these key items, it is likely to result in:

  • delays in meeting project dates,
  • disagreements on what the project is expected to deliver,
  • difficulty solving issues,
  • confusion on direction, work requirements, and status of the project,
  • lack of buy-in from team members and the end users,
  • additional stress and demands on the time of team members and end users, particularly near the end of the project,
  • less satisfaction from the client on the final delivered product.

{loadmodule mod_custom,ad 300×100 Large mobile}

Many types of documents, templates, tools, and strategies exist for managing a project.  This article will focus on 10 items that represent supported concepts in the project management industry and should, at minimum, be utilized for all significant application implementation projects. 

Related Article: A Project Manager’s Guide to User Experience

1. Solid contract with software provider

A verbal agreement won’t cut the paper it’s written on. Get it in writing! If a contract is already completed and these items have not been included, you should work with your vendor to reach agreement on these terms.  Additionally, you should work with your organization to see that these items are included in future contracts. 

The components that you will want to have well defined are:

1. a payment schedule,

2. outline system performance criteria,

3. penalties related to performance issues and delivery delays,

4. documentation requirements,

5. training, which is provided,

6. inclusion of a test system, and possibly a training system,

7. issue resolution/turnaround time/escalation policy,

8. and vendor support during and after the application live event.

Having these items defined contractually is an assist to the project manager.  It will provide you with agreed-upon criteria allowing you the leverage to hold your vendors accountable to their deliverables. 

2. Involvement by key staff and resources

The organizational structure of those involved in the project is a significant indication of the success of a project and is one of the first things you want to have in place to start the project.

Make sure to have a:

  • Project Sponsor. 

This person should be a senior manager head of the Steering Committee.  They will be the source who authorizes the project, ultimately ‘owns’ the project, and sources the funding for the project. They would not and should not be a member of the project team. 

  • Leadership Committee. 

This leadership committee is responsible for following the status of the project, representing the project to their peers and senior management, and assuring all of the appropriate parties are involved.  This group will make any decisions that the team cannot determine, they will assist rectifying business issues and with escalation of problems including to vendors or internal staffing. Use these people!  They are there for you.

  •  Project Team. 

These are the folks that are performing the work for the project. You may have several teams, or workgroups, with different focuses.   

  • Project Manager. 

Hey!  This is probably you! The Project Manager is responsible for overseeing that the work is getting completed as expected on schedule.  They manage any deviation from the scope or schedule to get the project back on track.  They are generally responsible for planning and often own and complete the project documents (such as the scope, staffing plan).

Additionally, consider the following while staffing the project team:

  • Be certain to include individuals who know the business.  If there are different aspects of the business involved in the project, include a representative from each of these areas.  These individuals will often serve the most benefit as project team members who are active in identifying processes, business needs, and performing testing and training. 
  • Consider a ‘superuser’ strategy.  This works well where individuals are identified early on in the project to serve as business/application experts.  They may be those who perform testing and training as well as first line support for end users.  These users can often serve as project team members.
  • A Project Staffing Plan should be completed to include the names of the individuals involved, the committee or teams that they are serving on, and the roles and responsibilities of those individuals and teams.  All team members, and their managers, should approve this plan so there is agreement on the expectations. 

3. Plan how the project will be managed

Create and share a Project Management Plan that will document how the project will be managed.  This should be agreed upon with the resources and management.

  • Document how changes will be handled, especially those that impact the scope, dates, budget, or resources.
  • Document how issues will be managed and escalated.
  • State how the schedule will be managed.
  • Include all methods of communications that will be used for the project.           
  • Once you review this with the team, you will likely be the sole audience for it.  Really, it’s not that entertaining and you shouldn’t expect others to be interested in it.  However, you will utilize the content to guide how various aspects of the project are to be managed and you may also refer to it if a deviation occurs where you need to reference the agreed-upon terms.

4. Define and agree upon the project scope

Write a project Scope, state what is and what is not included in the project. 

  • Document deliverables and assumptions.
  • Refer to any requirements that were gathered.  If no requirements were gathered, meet with stakeholders across the board to determine their requirements so that expectations can be documented and agreed upon.
  • Include Milestones, which are significant events, with their due dates.  Remember that “TBD” is not a date!
  • All project team members should understand the scope.
  • It is important to get formal approval from the Steering Committee on the scope before the project execution phases begin. 

5. Development and management of a schedule

A Schedule is the central tool to managing a project’s activities and keeping on track.

  • Develop a schedule that documents the tasks that need to be done to complete all of the deliverables outlined in the scope. 
  • Be sure to include dependencies, but not the work associated with those dependencies, on items that are outside the scope of the project.
  • Assign names and due dates to each task.  Does that seem obvious?  While it is probably obvious, it is not always done.  Oh, “TBD” is not a person either!
  • Items that risk a delay should be done as early as possible.  This may include such things as ordering hardware or scheduling training.
  • Highlight tasks that are milestones from the Scope. This will allow better tracking and reporting of those milestones.
  • Note items that are on the critical path (these are tasks that if delayed will delay the rest of the project).  Special attention should be paid to these tasks to keep the project on time.

6. Management of an Issues List

Having one central repository to log issues is invaluable. 

  • Each issue should include a clear description, name of who is assigned to own/resolve the issue, a due date, status, and priority.  If an issue is being resolved by someone who is not on the team, it should be assigned to a team member who is responsible for tracking the issue.  Another note, “ASAP” is not a date!  Your ‘soon’ and someone else’s ‘soon’ can be two entirely different times!
  • “High” priority should be reserved for those issues that, if not resolved, could impact the stability of the application, the integrity of the data, or completion dates of critical tasks and events. 
  • Track issues actively (daily or weekly).  Include new ones as soon as they arise.  Log updates to each issue as they become known. 
  • Document issues even if they are likely to be easily solved.  Those tend to be the ones that get away and should not be ignored.
  • Share the issues list with the entire project team; get updates regularly from the owners of the issues as well as team members who may have items to add.

7. Solid Testing

Testing is critical to understand how the application will work in the installed environment, if it performs according to expectations, and to identify any problems with the software or processes so they are addressed prior to the live event.

  • Document what type of testing must be done (i.e., database conversion, data flows, user front end, business flow).  Include who will be involved in testing and how it will be performed. 
  • Write Test Scripts that detail all scenarios that could occur.  Business end users should be involved in this as they are most likely to understand all aspects of their business. 
  • Test items that are standard operations as well as those items that occur infrequently.
  • Conduct user testing with staff members who are familiar with the business for which the application is designed.  They should be validating the application for their business.
  • Allow time in the schedule to retest anything that did not work initially.  If any changes are made to software or setup, run through most tests again to assure there is no negative impact in other areas.
  • Determine security access, setup, and test user accounts prior to live.

 8. Training Program

Proper training is essential to assure that end users are prepared to use the application.

  • Identify all users early on in the project; this will help to confirm all possible scenarios are covered and all users are part of the project communication.
  • Training will be optimized, and sessions better received, if individuals who will have similar use of the application are trained together. Also, if there are users who are not familiar with computer systems, consider holding a general knowledge training first.
  • If the possibility exists, allow the users to have access to the test or training system before the live so they can practice.  Consider providing practice scenarios for this occasion.
  • Create a Tip Sheet that is easy to read and highlights the top items a user would need to know.  This can be useful for the live as well.

9. Preparation for Live Event

A review of all deliverables and tasks should occur weeks before the system is ready for production use. 

  • Anyone involved in the project should verify that all tasks are completed, or will be completed as scheduled, for the live event. 
  • Issues should be scrutinized at this time so a decision can be made regarding their potential impact to the live.
  • Assign staff who have a good understanding of the application and business to assist users during the first days of production use.  Establish a central call number that is staffed with individuals who can track, solve, or escalate issues.

10. Communication

Communication is one of the key items recognized as leading to a successful project.  It should also be noted that in projects experiencing problems, communication is often reported as lacking.  So last, but certainly not least, are tips to improve this valuable activity.

  • Keep committees and teams informed.  The Steering Committee should be meeting at least once a month. The agenda should include a review of an up-to-date status report and focus on any issues or concerns with dates or deliverables. This committee should not be concerned with the work outlined in the schedule, but rather the higher-level milestones.  The same holds true with issues.  Only review high-priority issues that may have a negative impact on the project and not the entire issues list.
  • Team meetings should occur weekly or as needed.  Even a short conference call meeting can be effective to get everyone together. Those involved will have an opportunity to state something that may otherwise be overlooked. Status on the work being completed can be shared with all team members to assure everyone is in line with what is expected.
  • Monthly or weekly Status Reports should be completed and shared with all involved individuals.  The status report should include: status of milestones, recent work completed, what work is to occur next, high-priority issues, and changes to budget, scope, schedule, or resources.  This should not be a detailed account of activities but rather a summary.
  • Users should be informed of the progress of the project as it evolves.  Try to present them with demonstrations of the application in advance.  Distributing emails or newsletters are a good way to get information out and often receives a positive response.  End users do not need to know about problems, but the more they are involved with the status of the project, the more they will accept the change.
  • Remember that communication is vital to the success of a project.  It allows for establishing expectations and keeping everyone informed.  Only provide recipients with information they require and do not burden them with excessive details.  Different audiences may require different formats or content.        

Consider the above items when approaching your next project.  Although this article describes some instances specific to application-related projects, most strategies will be valuable to any project.

Don’t forget to leave your comments below.

Brenda Hallman has over 15 years of experience in project management, most recently in the Project Management Office at Main Line Health where she is responsible for standards, tools, mentoring, education, and program development for project management staff.  Ms. Hallman has a Bachelors of Science Degree in Computer Science and Mathematics from Edinboro University, a Masters Degree in Business from Penn State University, and a Masters Certification in Project Management from Villanova University.  She has worked in the information services arena initially in software development and later in project management.  She is PMP certified.

UAT Tips & Templates

Written by Abubakar Munawar on . Posted in Articles. 4 Comments on UAT Tips & Templates

What is UAT?

User Acceptance Test, or UAT or Acceptance Testing, all defines the single meaning.

According to The International Institute of Business Analysis – Body of Knowledge V2.0, User Acceptance Test or UAT is defined as “Test cases that users employ to judge whether the delivered system is acceptable. Each acceptance test describes a set of system inputs and expected results.“

User acceptance test refers to the satisfactory test of solution by users before moving the solution to LIVE Environment. In UAT, users of the software validate the maximum possible scenarios that may come in LIVE environment, which are tested in the solution and found to be accurate.

If UAT is about testing the solution, then a question comes to mind: “What do Quality Assurance departments do at their end when they say they are testing the application?” For that I would simply say, there is a 360-degree difference in both types of testing, and the biggest difference is the goal/objective of both.

The goal of software testing is “to make sure the software meets the specification” or “to make sure that the developed software is bug free.“

Whereas the goal of User Acceptance Testing is “to make sure that system completely supports the day-to-day business scenarios along with other known possible scenarios that may create a hurdle in business operations, and to make sure that software will not hurt the LIVE operation when it will be running in a LIVE environment.“

UAT is considered a final stage of any software development initiative. Without successfully completing the UAT, the project cannot be considered as completed nor does any client accept.

The Myth:

While discussing the project issues with different colleagues, friends, community members and others, I have found that many Business Analysts try to implement the system directly in a LIVE environment, i.e., user starts entering LIVE entries and when all entries are entered and reports are matched, the system is considered as implemented and signed off.

Exceptional/abnormal scenarios are part of routine business, and they are also very hard to recall/identify. In the earlier-mentioned situation, when the user was focused on testing the system based on LIVE entries only, he definitely loses the focus on those abnormalities that arise usually in his business transactions. Further, there might be some special cases that were handled in some other way by the users; those cases will also be missed in testing based on LIVE data. All of these abnormalities, special cases and others issues will come someday in the LIVE environment when the user will be using the software, which will be the time the user will say, “I used to solve this case by pressing that button in legacy system” or “I did this case by doing this, this and this,” and the vendor will ask for Change Request and two things will be charged (money and time), and due to time the business may suffer.

Consider the other scenario in which the user took his time with the business analyst and identified the maximum possible scenarios including normal/routine business transactions along with any abnormality or exceptional scenarios. And when the system is ready, users test all those scenarios in the system and after successful completion of testing, the system goes LIVE. This will minimize the chances of abnormality or exceptional cases in the LIVE environment.

Conducting UAT is equally important for both Vendor (Software Developer) and the Client (Software User). Thousands of reasons can be written on the importance and impact of not doing UAT; following, are some very important reasons for which UAT should be done in every project.

Reduce chances of error in LIVE Environment: Maximum possible scenarios are identified and tested before software moved to LIVE environment

Increase User Satisfaction: UAT provides full-fledge access of software to user, which gives him a lot of confidence as well as satisfaction to allow him to test the software that soon he will be using in a LIVE environment

Reduce risk of regulatory & other compliance: As in UAT, the system is tested on maximum business scenarios; the risk of regulatory and other compliances that may bring penalties in term of financial impact, opportunity loss or customer dissatisfaction can be minimized.

Reduce Time: In new/automated system, there is a chance that the system has automated some business processes along with some changes in existing processes, which might have increased some process steps found to be unnecessary or wasting time in the LIVE environment, UAT allows users to identify those unnecessary steps before going into the LIVE environment, it allows organizations to save time by reducing process steps that may take time in the LIVE environment and incur extra costs.

Business reputation: If due to software solution, organization is unable to provide the services to its customer or provide the services with delay or somehow impact customer by giving wrong figures or showing wrong transaction in customer’s account, this may blow the business reputation and definitely results in customer dissatisfaction, and with this, the company may lose a good amount of business that was successfully in hand having the legacy system in place.

Role of Business Analyst in UAT

Business Analyst as a neutral, non-technical, business side representative makes a good UAT conductor. Due to his focus of solving business problems, independent from developer and not having a technical mind, he can easily think in the shoes of the customer to identify the normal as well as complex, uncertain and abnormal scenarios along with real like data and help users in testing the same before going into the LIVE environment. And finally, the Business Analyst has a vested interest of high-quality software along with the solution of the business problem with value addition and so is motivated to perform rigorous testing of the system.

Skills Requirement of Business Analyst for UAT

As mentioned earlier, UAT is the last and final stage after which the system will go LIVE, and therefore, the crust of this activity is to make sure that maximum scenarios are tested in the system and if issues are found they are reported accordingly. Due to the criticality and importance of the UAT phase, the role of the UAT conductor requires multi-faceted skills. These qualities allow the person playing that role to perform this important activity; the business analyst must think in the shoes of the user to understand his problem. Absence of these skills may fail the overall UAT phase.

Further, following skills and competencies are required to be possessed by the Business Analyst to conduct effective/successful UAT:

People Handling: Business Analyst that holds good skills of people handling and can develop a good relationship with users in order to explain his point of view, and that skill also helps business analysts to understand the point of view of users. In UAT, users sometimes try to resist change or try to imply his point, but having a good relationship with the business analyst, the issue of ego doesn’t come between and things get concluded in a positive direction.

Domain Knowledge: As quoted in every business analysis-related article, “Domain Knowledge is mandatory for Business Analyst.” Off-course[G1] , if a business analyst lacks the domain knowledge, he will not be able to conduct the successful UAT. Due to his limitation in business knowledge, he will not be able to identify the business scenarios, nor can he help the user in identification of the same, and also will not be able to question the wrong scenarios or wrong practices that the user requires to be added as scenario in the software.

Software Functional Knowledge: You must have heard a business analyst saying, “I need to talk to my technical team to get the idea how this screen will work?” Consider the confidence level of the user on the business analyst and software when a person who is facing him is telling him how to do UAT? Don’t know about his own solution.[G2]  Business analysts must understand the inside out of the whole solution; I would say, “He should be the person who has maximum knowledge of software working.” With this skill set, he can conduct efficient UAT, as the issue of stuck due to software functionality.

Executor, Initiator: Business analysts should have the skills of execution; he should have the ability to drive the users according to the UAT Plan and in case of any issues related to user availability, system errors, other resource availability, any other showstoppers or issues of progress, he should escalate it to the right person immediately without wasting time. Business analysts should observe the situation and inform the relevant stakeholder in case he senses some risk or issue that is arising.

Positive Attitude: Business analysts should always maintain a positive attitude and consider the comments of users as areas of improvement and act accordingly rather than start being defensive or sometimes offensive about it. He should understand the user’s point of view and in case the user is of a different mindset, try to convince him positively with rationals[G3]  and arguments to support his opinion.

Common UAT Problems Faced by Business Analysts in UAT

1. User Availability: Issue # 1 of any UAT, even if users are marked as fulltime user to the project, still they will not be able to give you required time, due to their involvement in day-to-day operations. As most of the time organizations find it difficult to execute the full-time strategy, because the user assigned to automation project are usually more skillful than others in their department, and assigning them to the project for fulltime impacts the day-to-day operations of the organization, and if the organization is ready to do so, it will require their users’ interactions, which again impacts the user availability for UAT. Therefore, business analysts should maintain the record of user availability and escalate if user is not available as required for UAT.

2. Detail-Oriented Personality: There are some users who have a very detail-oriented personality or, in order words, they are perfectionists. These users are very hard to handle due to their expectations and requirements; they always want everything completed precisely and in detail. And their focus on detail drives them to the complex scenarios that a business has never faced before and might not face in the future as well, but they insist on testing those scenarios or handling of those scenarios in the software. That type of personality eats your UAT time like a grasshopper eats the grass. And as they are perfectionists, it is usually hard to explain your point of view to them and they also sometimes face problems in understanding the point-of-view of others, which moves the UAT phase into a never-ending cycle. But the important point that should be highlighted here is that this type of personality is problematic in UAT but can be good utilized in the requirement phase due to their detailed understanding of the business process.

3. Overlooking Personality: In UAT, you may face a personality that is easygoing and will not put required efforts on details of the system and its testing. This is the personality that will tell business analysts that “Everything is fine, all is good.” That type of personality focuses on getting things done with simplicity; they sometimes do it because they don’t know about the pain they will be facing if UAT is not done effectively. That type of personality is very high risk for UAT as the chances of overlooking functionalities are too high, and Business Analysts should identify that personality and handle it by going into every detail and letting that user think that BAs want him to go in detail along with escalating the issue to the right level if required.

4. Issue Log Management & Prioritization: In UAT, many issues are identified, and if they are not logged and prioritized at right time, the whole UAT exercise will go wasted. While doing UAT sessions, the user identifies many issues related to application, and there could be a lot of issue types, some of which could be “GUI Related, Logical Observation, Application Bug, Business Not Mapped” etc. The bigger software has a greater type of issues along with their number as well. As a BA, you should follow a good mechanism of logging and managing the process of issues. Every issue reported should be logged-in in enough detail to be understandable by the user and technical TEAM both, as those issues will finally be reported to the technical TEAM for resolution. BAs should also consider scoping at this level, because there might be some issues that were not in initial scope due to “requirement not discussed” or some other reason. Those issues should be reported in log but BAs should identify them as “Out of Scope” and set the expectation of the user that this will not be handled in the current release of the software.

5. Understanding of Requirements: It has been observed that Business Analysts who are conducting UAT with user and were part of the initial requirement phase (Software Requirement Specifications Phase) were able to conduct the UAT more effectively than the business analysts who are assigned directly to UAT without their involvement in SRS Phase. This is due to the understanding of requirements, as if the BA is involved in the initial requirement phase he would have better and a detailed idea of what the specific requirement is all about, and if he is not, he might have his own point of view in place for specific requirements that create hassle for the user who is doing the UAT. Therefore, the recommendation is the BA who is doing UAT should be part of the initial requirement phase, and if he was not, he should go through each requirement in enough detail to understand the different aspects of requirement and its implications.

6. Complex/Demotivating/Offensive Personality: In projects, you face different types of personalities, and all of them impact the project in different ways at different stages. You might have seen some personality in your projects who used to say, “This project is not going to work,” “This project is Pandora’s box,” or my favorite, “We are playing GIGO (Garbage In Garbage Out).” Complex, demotivating or offensive personalities exist in projects and BAs cannot afford to avoid them. Good BAs should understand how to work with those personalities And how to get maximum out of them without going into never-ending arguments. These types of personalities are not very hard to handle and Business Analysts can handle them by maintaining his positive attitude, good relationships with individuals and good arguments to support his decision every time. And if things get uncontrollable, then BAs should know when and to whom the matters should be escalated.

Tasks performed by Business Analysts in UAT Phase

While doing UAT, business analysts perform different tasks based on the type of projects, duration and organization standards. The following tasks are generic to be followed in every UAT:

  1. Solution Validation: Validate that solution meets the Business Requirements
  2. Verify the Organization Readiness: BA should make sure that the end user is ready to use the software, by checking that the required resources along with relevant tools and trainings are delivered
  3. Identification & Validation of Scenarios: BA should identify scenarios that will be tested in UAT Phase and get those scenarios validated from end user
  4. Create Training Plan: BA should publish the training plan to engage the required resources
  5. Create UAT Plan: BA should publish the UAT plan so that required resources can be arranged
  6. Conduct the training of software: BA should allow user to do hands-on UAT by providing training of software, so that user satisfaction can be achieved
  7. Conduct UAT: UAT should be conducted keeping in mind the objective of UAT, which is to “make sure that system fulfills the day-to-day transaction of business along with any other known exceptions”
  8. Record the Results: UAT can only be effective if issues are logged religiously
  9. UAT Feedback: BA should from time to time confirm from user that solution fulfills the business needs as anticipated by user and update the feedback to related stakeholders
  10. Conduct UAT Signoff (Approval to GO LIVE)

Documentation created by Business Analyst in UAT

There could be different sets of documentation a Business Analyst does in UAT. The type and level of documentation is totally based on the methodology of the overall project, type of project and organization standards. E.g., By following the Water Fall, methodology in overall projects the level of formality in BA documentation becomes high and the number of documents increased, whereas in Agile there are low numbers of documents due to the low level of formality.

Following documents has been found to be useful for Business Analysts in the UAT phase; for better understanding, the list of documents is divided into sub-phases of UAT: 

UAT Planning

  1. for UAT (Must Have Document) & Business Scenarios Download Template 1 Template 2

  2. Business Process Flows to make sure that user is doing the right things (Must Have Document) Download Template
  3. Application Process Flows to map the business process on application to support user in identifying the relevant screen for each business process step (Must Have Document) Download Template
  4. Deployment Things To do to make sure setup/primary data is ready with user before initiating the UAT along with any other resources (users, trainings, machines, etc.) that are required for UAT Download Template
  5. Deployment Slip on successful deployment of application on client premises Download Template
  6. Training Plan to schedule the resources required to provide software training to users (Must Have Document) Download Template
  7. Training Script: This document is to prepare BA for the training and UAT session, in which BA identifies what screens he will be training and by entering what data and how?
  8. UAT Plan to schedule the resources required to conduct UAT (Must Have Document) Download Template

UAT Execution

  1. Training Signoff: User has accepted that training is done (high formality) Download Template
  2. UAT Issue Log: Should be maintained at any cost and shared with all stakeholders (Must Have Document) Download Template
  3. Daily UAT Summary to inform all stakeholders about the daily progress of UAT (Must Have Document) Download Template

UAT Closure

  1. UAT Signoff is authorization from user to GO LIVE Download Template
  2. Customer Testimonial

Don’t forget to leave your comments below.

Abubakar Munawar, is a Trainer, Mentor and Consultant for Business Analysis, Process Improvement & Reengineering. He is a Business Graduate with over ten years of experience in Business Analysis, Software Designing, Development, Quality Assurance, Implementation Project and Product Management. He is working in Lucky Cement Limited as a Deputy Manager Information Technology and earlier he was a Project Manager & Lead Business Analyst with Plexus Private Limited for Investments Applications Division. He has conducted many corporate training programs for in-service personnel of large organizations in Pakistan.

From the Sponsor’s Desk – Pulling the Project Plug

Written by Drew Davison on . Posted in Articles. 7 Comments on From the Sponsor’s Desk – Pulling the Project Plug

In my last post, Building Project Management Maturity, we looked at a company that found itself at a competitive disadvantage because of their project management performance and the steps they took to improve their performance and capability and level the competitive playing field.

In this post, we’ll look at the value that a mid-project audit can provide by helping stakeholders confirm or rethink the motivations and rationale for an initiative. In this case, the audit helped avoid potentially costly enterprise wide conflicts through a change in corporate priorities.

The Situation

This Canadian based mining company had contracted with one of the “Big Four” accountancy firms to assess the organization’s readiness to implement the International Financial Reporting Standards (IFRS), determine the impact on their world-wide operations and recommend an appropriate plan of action.

While European public companies have been applying these standards since January 2005, in Canada, the Accounting Standards Board had proposed that Canadian GAAP for publicly accountable enterprises migrate to IFRS over a transition period. The move to IFRS would impact many areas of business including fundamental decision-making processes and would change the way companies presented their business results to analysts, investors and other stakeholders.

The Goal

The company planned to develop and implement IFRS compliant practices and procedures throughout its global operations in accordance with the targeted transition period.

The Project

The Finance organization launched the IFRS initiative and contracted with the accounting firm which assigned senior consultants who had extensive experience planning and implementing IFRS solutions in Europe. A working group was established to liaise with the consultants and included Finance department managers and staff with some consultation with the head office IT organization.

As the consultants were wrapping up their IFRS assessment, the head of the Internal Audit organization heard rumblings from the regions concerning the work being done, its complexity and the regions’ lack of involvement to that point. He proposed to the Finance VP that an audit be done to assess the performance of the project to date, identify gaps and target opportunities to provide the foundation for a successful implementation. His recommendation was approved.

Internal Audit launched the project audit using the Project Pre-Check’s Diagnostic process. The assessment started with the identification of key stakeholders from all global operations and involved interviews to solicit their views on progress to date and thoughts and suggestions on future plans.

The assessment process used a selected subset of Project Pre-Check’s Decision Areas (47 of the 125) covering the nature of the planned change, the environment within which the change would be implemented, organizational processes and practices that could be leveraged and the management of the project itself. The 47 Decision Areas were used to gauge three perspectives:

  1. Stakeholder views from face to face and phone interviews, including stakeholders from the corporate office, from the regions and the consultants.
  2. Review of deliverables from the project to date
  3. Review of any project management methodologies, practices and templates used.

The interview results found that the IFRS project’s overall level of stakeholder agreement at this stage of the project was 2.4 on a scale from 1 to 5, based on the following definitions:

1 – Not addressed, don’t know or disagree with current decision

3 – Somewhat addressed

5 – Completely addressed

The interview results identified 7 of the 47 Decision Areas addressed in the assessment

(15%) as areas of divergence (at least one of the stakeholders was less than comfortable with how a best practice was applied). 40 Decision Areas (85%) where identified as gaps (where the majority of stakeholders expressed a lack of comfort). The results showed that these challenges needed to be addressed posthaste to avoid a less than successful outcome.  

Key areas of concern were those areas relating to the scope of the project, organizational priorities, the target dates, stakeholders (confusion over the sponsor and project manager), decision making responsibilities and ongoing governance.

The audit took about six weeks to complete. The Audit leader presented the findings and recommendations to the Finance VP. The recommendations included:

  • Confirm the sponsor and project manager
  • Form a stakeholder group including stakeholders from all affected organizations
  • Establish the priority of the IFRS initiative relative to other competing projects
  • Work towards full agreement on all 47 Decision Areas included in the audit.

The Results

The project was deferred! After reviewing the audit results and conferring with stakeholders in head office and the regions, the Finance VP acknowledged that the IFRS project would face significant risks trying to go head to head against other initiatives that were judged to have higher corporate priority.

The audit helped bring the disparate views of the stakeholders to the surface and escalate the concerns about corporate priorities to the executives who had the information and authority to make the right call. Prompt action by the Audit head and a comprehensive six week review focusing on the key project stakeholders helped this company make a timely decision and avoid the financial and operational risks of too many projects chasing too few critical resources.

How a Great PM Could Have Helped

The IFRS project was at a disadvantage from the moment it was launched – it had no internal project manager. Sure, the consultants managed their piece of the work. But no one from the company was formally responsible for managing the changes to the company’s practices and operations from inception to successful delivery.

Had a Great PM been assigned, undoubtedly he or she would have addressed the following fundamentals:  

1. Establish the project’s sponsor clearly and publicly. On the internal project documents and the report prepared by the consultants, three different sponsors were identified. That’s a recipe for chaos. Even co-sponsors can lead to muddled and circuitous decision-making. Pick one!

2. Identify and engage the other project stakeholders across the enterprise and around the globe and ensure that they understand their roles and responsibilities. All stakeholders – the sponsor, targets, change agents and champions – need to contribute according to their responsibilities on a multitude of fronts for the project to be successful.

3. Manage the level of stakeholder agreement on the relevant decision areas. Work to resolve the gaps and areas of divergence up front and on an ongoing basis as new issues and conflicts crop up. Early estimates of the cost of the IFRS project ran in the $8 million to $10 million range to be implemented over an 18 month period. That means navigating a mountain of mole hills. A Great PM would thrive on that challenge.

4. Managing stakeholder agreement on the relevant Decision Areas will help a Great PM ensure that critical questions about the planned change and the environment within which the change is being implemented are addressed. A Great PM will ensure that the impact on and/or use of appropriate company assets (methodologies, practices, resources, etc.) is fully articulated and endorsed by all. Finally, a Great PM will ensure the approach to planning organizing and controlling the project is fully supported by the other stakeholders and that project communications address their collective and individual needs.

If you find yourself in a similar situation, put these points on your checklist of things to do so you too can be a Great PM, and your sponsor’s best friend.

Next, we’ll look at the challenges a Great PM faced as he tried to guide the upgrade of extremely out of date but mission critical content management software through the demands of the business and the ineptitudes of two external contractors. In this case, the Great PM’s tough love approach won the day, and a successful project.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don’t forget to leave your comments below.

Agility is Essential but Process is Not

Written by George Pitagorsky on . Posted in Articles. 6 Comments on Agility is Essential but Process is Not

FEATUREJuly201A recent response to a blog post said that “agility is essential but process is not.”

Let’s be clear about the relationship between process and agility. There is always a process — a set of steps to accomplish something. Agility is an attribute of process.

A process may be agile or rigid to one degree or another, more or less heavy or light, defined or not, effective or ineffective.

Agility is Necessary

A process that is agile is more likely to be effective than one that is rigid, particularly when what is being done is complex and subject to change. Why? Because the ability to adapt is necessary if objectives are to be met and people’s expectations are to be satisfied, especially in a volatile environment in which there is uncertainty about requirements. 

For example, if you are trying to create a web site to satisfy the needs of an organization, attempting to document all the requirements fully before beginning the development is often not an effective approach. If an IT process is followed so that requirements documents must be completed in great detail and accepted, and every change thereafter must go through a formal change control process, there is high probability that the client will be frustrated as will the project team. Why would anyone follow such a process? Because they are codified and institutionalized; they are the rules.

Agility in this case would enable developers to work directly with clients who can make decisions about functionality and format as the site is being built. Functionality would evolve as the site is delivered and put to use.

Process is Necessary

Agility without a well-defined and effective process is chaos. It risks shortsightedness — creating a product that is not easily enhanced, for example.

In the case of the website, one aspect of process is the decision-making as to whether the project should be undertaken and how it should be managed; whether to use an Agile approach, how to capture performance data (e.g., the number of hours worked on components) and report on progress, and what kind of documentation is needed.

Other aspects are the way requirements and changes are to be handled, how design constraints and reviews are to be done, who will do testing and how they will do it.

Further, a process for product planning is needed to provide, in broad brush strokes, a road map of where the development is headed.

Maintaining the Right Balance

The notion that Agile approaches are without process is just plain wrong. If you analyze a methodology like Scrum, you can clearly see that there are role definitions, prescribed techniques, tool utilization and more. These add up to a defined process.

The Right Balance

The trick is to be able to strike the right balance. The process needs to include a clear understanding of where, when and how to change the process.

If change can take place on the fly, decided by the performers themselves at the team level, then the process is highly flexible. But for this to work in an organization, there must be standards and policies to guide and constrain the change. There must be well-trained and relatively clever performers who take responsibility for their actions and recognize the need to address both short-term and long-term objectives.

Not every team or individual has the wisdom to do the right thing. Some are so focused on the needs of the moment that they make decisions that restrict future growth and sub-optimize the overall process or program that the project is part of.

It’s like the old Zen parable about keeping horses. Give them unconstrained space and they’ll wander away. Put them in too tight a pen and they’ll kick their way out or get so still that their muscles will become weak and they won’t be of much use. Put them in a large enough controlled space and they’ll be happy and healthy. When they get to the fence, they’ll turn in another direction because there is no need to jump the fence.

The point is that we need constraints and defined processes but they must add value to both the project and the broader context of which the project is a part of. We need an effective, flexible process that gives people the ability to adapt to the needs of the current situation while adhering to best practices and coordinating within the bigger picture.

Don’t forget to leave your comments below.

Five “Simple” Questions to Facilitate Project Selection & Prioritization

Written by Kiron Bondale on . Posted in Articles. 5 Comments on Five “Simple” Questions to Facilitate Project Selection & Prioritization

Don’t misunderstand me – project evaluation or prioritization is NOT simple – getting a team of decision makers to come to an agreement on a ranked set of projects while putting aside their individual agendas such that the organization’s objectives are met can make achieving world peace appear trivial! 

While I’ve covered in a past article on the project scoring that coming up with a scoring model for a project can be a key input into the decision making process, starting with a consistent set of questions can provide an objective counterpoint to balance the expected project “lobbying” from decision makers.    

The following standard domain and industry-neutral questions could kick start this shift.

1. Which business or operational metrics are expected to be improved by doing this project and by how much?

Regardless of what industry you operate in, all “worthwhile” projects should result in improvements to at least one business or operational metric.  In some cases, you may not have previously quantified the metric, but that doesn’t mean it doesn’t exist.  For example, a project to train internal IT staff on a new technology may not directly impact profitability, but it could improve the capabilities of the organization and could boost employee morale, both of which could be distilled into metrics.

2. Which business or operational metrics are expected to be negatively impacted by doing this project and by how much?  

Positive changes in one area will often result in issues to another, and these negative impacts need to be weighed against the benefits expected from the previous question.

3. What is the expected financial and resource burden of this project and over what time period? 

Cash-strapped companies might be tempted to focus on financial requirements only, but poor use of resource capacity is one of the greatest opportunity costs an organization can incur.  Both one-time and ongoing requirements need to be considered.

4. Does this project satisfy an external regulatory or contractual requirement? 

Unfortunately, there will always be some projects that have to be executed to keep the company compliant.  This is why it is important to ensure that the cure is not worse than the disease as I had covered in this earlier article.

5. How severe is the project & business risk? 

Ignoring negative project risks (i.e. those potential events that could impact the project’s objectives & constraints) or business risks (i.e. those potential events resulting from the project that could impact the realization of the project’s benefits or the business as a whole) will be like jumping out of an airplane without checking that your parachute is viable.

Expending excessive effort in developing a detailed scoring model is academic if executive leadership behaviors don’t change, but consistent evaluation and presentation of holistic project information is one way to start the transition to a more objective approach. 

Don’t forget to leave your comments below.