Skip to main content

Tag: Facilitation

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.

Managing Projects over Multiple Organizations

Written by Thomas B. Clark on . Posted in Articles. 3 Comments on Managing Projects over Multiple Organizations

One of the difficulties of managing projects that involve several (perhaps many) organizations is that the group has no pre-established procedures for handling actions that cross organizational boundaries. Such actions often include:

  • Technical decisions (e.g., specification or design changes)
  • Managerial decisions (e.g., schedule changes)
  • Administrative processes (e.g., issuing payments for work)
  • Project activities that involve more than one organization (e.g., approvals or inspections, placing purchase orders)

If such inter-organizational actions are not anticipated and procedures put in place to guide their performance, confusion and miscommunication will result, which will lead to unnecessary delays, wasted resources, and potentially even conflict among the organizations.

The development of operating procedures for multi-organizational projects can be facilitated by the use of a tool known as a “linear responsibility chart” (LRC). Consider the hypothetical and simplified example illustrated on the next page. Cavendish Chemicals is planning the design and construction of their new Plant Clearwater. The project will involve the individuals, departments, and organizations shown in the columns of the chart. The inter-organizational actions that can be anticipated on this project are listed in the rows of the chart. Several responsibility codes (letters) are defined in the upper left corner, and these codes are used in each cell of the chart to indicate the responsibility or responsibilities of the entity in that column relative to the action in that row. By reading the codes in any row of the LRC, it is possible to ascertain an overview of the procedure for the action associated with that row.

The LRC, however, is not intended to be an end in itself. Rather, the LRC is an efficient tool that is used to collect and verify information about how the organizations intend to work together, so that written procedures for each action can be developed quickly and with minimum rework. The process involves several steps as follows:

  1. Identify the individuals, departments, and organizations that should be represented in the chart and develop the column headings for those entities.
  2. Develop an initial set of responsibility codes, such as the codes shown in the example.
  3. Interview the project manager. Make an audio recording of the interview. Ask the project manager to:
    • Identify inter-organizational actions that should be included in the chart and ultimately in the project procedures manual. Enter these actions in the rows of the chart
    • Talk through the procedure for each action as he or she would prefer that it be performed. Enter responsibility codes into the cells of the chart to capture the procedure as described. If necessary, create additional codes.

Cavendish Chemicals, Inc.
Linear Responsibility Chart
For Design and Construction of Plant Clearwater



RESPONSIBILITY CODES

INDIVIDUAL / DEPARTMENT / ORGANIZATION
A. Requests / Initiates
B. Performs / Takes Action
C. Must Be Consulted
D. Must Approve
E. Must Be Informed

Cavendish Chemicals

 Architect General Contractor Subcontractors Equipment Vendors EPA County Bldg. Inspector
VP – Production Project Manager Process Engineering Plant Engineering
ACTION
Process design specification changes D E A/B C E E E D
Plant design changes E E C A/B C C E E D
Design schedule changes D B A/C A/C C
Construction schedule changes D B A C C E E
County inspections E E E A E B/D
EPA inspections A E E B/D
Owner inspections E B/D E E
Payments B D D A A A
  1. Interview other key individuals who are identified in the LRC or who represent departments or organizations identified in the chart. The order in which these interviews are conducted is not critical. Show each interviewee the actions that have been entered into the LRC by previous interviewees. Ask the interviewee to identify additional actions that should be included and to describe the preferred procedure. Again, enter the appropriate codes in the LRC, create additional codes if necessary, and make an audio recording of the interview.
  2. When the interviews have been completed, hold a meeting of the key individuals who are identified in the LRC or who represent departments or organizations identified in the LRC. Make an audio recording of the meeting. Give out copies of the LRC.
    • Explain the procedure for each action as described by the responsibility codes. Ask for comments, suggestions, or concerns on the procedure for each action. Seek consensus on all changes. Make changes to the codes as appropriate.
    • Ask for any additional actions that should be added to the LRC. Have the group discuss the preferred procedure for any such actions and record the appropriate codes on the LRC. Again, seek consensus.
  3. Using the LRC (and audio recordings as necessary), develop a project procedures manual. Each row on the LRC should be converted to a written procedure. Each procedure should have:
    1. Date and draft numbe
    2. Action name/description (e.g., “Construction schedule changes”)
    3. Statement of the procedure based on the codes in the LRC. In addition, the statement can contain details, such as:
      • When making a submittal, exactly what documentation to provide and to whom it should be sent.
      • How long an entity normally has to review and act on an item submitted for their approval.
      • Who should receive copies of certain communications.
      • Whether hard copy or electronic communication are required/allowed.

Signature lines for the project manager and for other key individuals who are identified in the LRC or who represent departments or organizations identified in the LRC. The signatures indicate that these key individuals approve the procedure and that they will follow and require other members of their organization follow the procedure.

In addition to the individual procedures, the procedures manual should contain:

  •  
    •  
      • A table of contents
      • A directory of key individuals involved in the project, including phone numbers, mailing addresses, and email addresses
      • The final LRC on which the procedures are based
      • A glossary of terms, if necessary
  1. Distribute the procedures manual to all involved organizations in hard copy and/or electronic format.

The early development of a procedures manual as described above has proven invaluable on projects involving multiple organizations. The application of the LRC in the context of the steps outlined above greatly facilitates the process, and it ensures that the procedures manual is complete and represents consensus among the involved organizations.

Don’t forget to leave your comments below

Thomas B. (Tom) Clark, Ph.D. , Co-founder and former Executive Vice President of Project Success Method and Project Success Inc., Tom is heavily involved in the development and delivery of PSI’s courses. In addition to his work with PSI, he is Professor Emeritus of Management at Georgia State University. He also served the University as Chair of the Department of Management and as Interim Dean of the College of Business Administration. Previously, he was an Assistant Professor of Industrial and Systems Engineering at Georgia Tech. Tom has provided project management consulting and training services for a variety of business, government, and non-profit organizations. Prior to beginning his academic career, Tom served in the U.S. Army Management Systems Support Agency at the Pentagon and was employed as an industrial engineer with a national firm in the printing industry. He holds bachelors and masters degrees in Industrial Engineering from Georgia Tech and a Ph.D. in Business Administration from Georgia State University.

PSI consultants have been engaged in more than 10,000 projects in 25 countries on six continents. For more information contact [email protected] This e-mail address is being protected from spambots. You need JavaScript enabled to view it or visit www.projectsuccess.com.

Using the Requirements Creation Process to Improve Project Estimates

Written by Curt Finch on . Posted in Articles. 5 Comments on Using the Requirements Creation Process to Improve Project Estimates

Estimation can be one of the most difficult parts of a project. Important questions must be asked in order to form the right figures and plans. How long will the project take? How many resources will it consume? Consultants may also ask the following question: What is the appropriate amount to bid on this project? These questions are not easy to answer at the outset when one generally has only a vague idea of what will be required throughout the project.

The good news is that there is a fairly simple way to improve project estimation and, consequently, the bidding process. Most people do not realize that the requirements creation process can lend insight into the length and scope of a project. Let me give you an example of how this method works and then explain how you can implement it within your own company.

The Story

Back in 1992, I was working for a consulting company named The Kernel Group (TKG). During this time, I was put in charge of porting Tivoli’s software from Sun’s Solaris operating system to IBM’s AIX operating system. The project was to be done under a fixed bid, and consequently, we at TKG knew that estimating the effort required to port the code was of paramount importance.

I looked at the code with a coworker of mine, and he came to the conclusion that if Tivoli didn’t make the project hard for us in some unspecified way, we could port the million or so lines of code in about a weekend. I told him that he was nuts – that it would take at least a week, maybe even two. We jointly decided that we probably ought to call it three weeks just to be safe. We also decided, rather smugly, not to report our padding of the schedule to evil upper management.

As a result, evil upper management drastically expanded the project bid to $325,000, and my coworker and I thought that this was a ridiculously high price. We believed that we were gouging the customer and that they would never accept it.

Yet they did accept it, and once the project began, we proceeded to discover how truly terrible we as software engineers were at the task of project estimation. To make a long story short, the porting schedule expanded to exceed our original estimate and we consumed not only all of the $325,000, but a whole lot more on top of it.

The Formula

Now our consulting company was religious about tracking employee time on a per-project basis, and so we broke every project into phases: requirements/specification, design, coding, testing, debugging, documentation, training, etc. This project was no different in that respect; we broke it down into its respective phases as well.

Just before we started working on the project in question, I read a book called Practical Software Metrics for Project Management and Process Improvement by Robert B. Grady. (By the way, this is a truly fabulous book that I would highly recommend to anyone who is managing software development projects.) According to the book, one of Grady’s rules of thumb is that 6-8% of every software project is usually eaten up in the requirements/specification phase.

One of the conclusions that Grady comes to in his work is that you can use this fact to estimate total project size. In other words, if it took 60 hours to do the specification, that’s probably 6% of the job and the job will be 1000 hours. Following such logic, a six hour specification implies a 100 hour job. Since the specification always comes first in any project, you can get some pretty reliable estimates from this method alone. In fact, in my experience as both a programmer and the CEO of a software company, I have found it to be incredibly accurate and useful.

A second way to triangulate this project estimate is to ask experts in the area for their opinions – hopefully they will be better at project estimation than my coworker and I were that first time. A third way is to select an appropriate metric for estimation. For example, one could use line of code counts or function points in estimating the length and scope of software projects. For architecture projects, you might use number of pages in the drawings or square feet planned as similar analogies. Every project has some gross measure of its size that is available at the outset and can be used to plan the overall project in addition to this method I’ve described of tracking time against the earliest phases.

So back to the story. We really blew it on estimating and bidding on that first project for Tivoli, but when the next one came around, we had data on the portion of the overall project that the requirements phase had taken up. This allowed us to use Grady’s ratio to predict overall project size, and we found that on this second project, we came up with a very accurate project estimate. This worked very well for all of the subsequent fixed-cost consulting work we did for Tivoli.

Partially due to the strength of the solution and how well it ran on IBM’s AIX operating system, Tivoli was able to eventually sell their company to IBM for 743 million dollars in 1995.

For a consultancy that is doing fixed-cost projects, this concept of using the standard ratio of requirements phase to overall project length is a very powerful project estimation technique. It can eliminate erroneous bidding and its resulting costs, which is a major concern for such companies.

Accurate Bidding

Overbidding on a consulting job means that you won’t get the work in the first place, because the potential customer will give it to your competitor at a cheaper price. Underbidding, however, means you will win the deal and lose money. Neither situation is acceptable for businesses today, and yet, most consultancies do a poor job in this area. One way to make more precise bids is to use a key performance indicator, which is a tool used to measure progress towards a strategic business goal. For example, the number you want to minimize in this situation is defined by the formula [(E-A)/E], where:

E = estimated hours to complete the project
A = actual hours spent to complete the project

It is important to keep this KPI value as close to zero as possible, which indicates that you are bidding on projects more accurately.

Just tracking this number is a great first step towards better bidding, and you can get the necessary data to calculate it from any timesheet system, including a paper one. Automated timesheet systems, however, are generally even more effective in this area because they often have reports to calculate the KPI figure for you.

Improving adherence to your estimate can be difficult for some companies until they understand the ratio concept described above. An example of this is illustrated in the following diagram, which shows how the formula can work for any business. Your company’s magic number may not be 6-8% like Grady’s, but once you determine your own ratio for specification to total project length, you can use it again and again.

usingtherequirements1

Making it Work

I currently run a software company, Journyx, and I can assure you that this project estimation technique continues to be successfully employed by many of our customers to their great advantage. It is easy to implement and you can do it too. Once you do, you will start producing laser sharp estimates before you know it. And that’s a result we can all feel good about requiring.

Happy estimating!

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx. Journyx offers customers two solutions to reach the highest levels of profitability: Journyx Timesheet – a timesheet and expense management solution for the entire enterprise – and Journyx ProjectXecute – a solution that unites project and process planning with resource management. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyze information to discover profit opportunities. Curt is an avid speaker and author, and recently published “All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.” Curt authors a project management blog and you can follow him on Twitter.

What Can Be Done To Ensure Projects Are Successful?

Written by Cynthia Low on . Posted in Articles. 5 Comments on What Can Be Done To Ensure Projects Are Successful?

  • Projects Run into Trouble and Does Anyone Care? Leroy Ward takes a close look at the failed project situation. He reviews the findings of various research projects and offers his thoughts on what can be done.
  • Leveraging Project Portfolio Management to Implement an Effective IT Governance Strategy. With a focus on IT Keith Carlson reminds us that governance is not just about compliance but also ensuring that it has the best possible impact on business. It’s about producing value and managing risk.
  • A Second Look under the Hood of the BA/PM Position Family. In this episode of Bob Wysocki’s series of articles about the relationship between the Business Analyst and Project Manager, he takes a closer look at where they overlap.
  • The Rules of Lean Project Management; Part III. Claude Emond, just back from a trip to the Far East gets back to the blog subject he was discussing before his travels. In this issue: The Expanded Management Team.
  • Now Stop Wasting People’s Time! Wasting no time, Ilya Bogorad races to the point of his blog. In very quick order he gives us five tips to help get the job done and “stop wasting time!”
  • Managing Expectations; the Key to Your Success. In his blog, David Barrett talks about the importance of setting objectives, communicating them, and keeping an eye on the target.
  • Leadership Skills for the Technical Professional. “Over 70% of all technical professionals have to be leaders,” says Richard Lannon in his Webinar.

Along with these articles and blogs and the first of our Webinar series, you’ll find many other features in this Project Times. We hope you’ll check them out and let us know what you think. Contact us at [email protected].

What Does Your PMO Do?

Written by Mike Lecky on . Posted in Articles. 4 Comments on What Does Your PMO Do?

It’s a good idea for anyone wishing to improve their organization’s project capabilities to take stock of the PMO functions they already have. Several models for PMOs exist to help you better understand the needs of your organization and how building certain capabilities and competencies in your project office can help. There are as many PMO models as there are PMOs, so developing a specific understanding of what functions your PMO must have to best support the business is important to be successful.

One model I used to like compares various project management offices with familiar functions. For example, the project office can be viewed as a weather reporting office, reporting status information and giving insight into the health of projects. Or as a lighthouse, providing assistance to projects in the form of guidance, processes and best practices as they pass through their life cycle.

While the pictures conjured up by these comparisons are illustrative, I find they don’t hit the nail on the head when it comes to broaching the PMO as a key organizational and structural element intended to support the business. Increasingly companies, especially larger ones, are attempting to develop PMOs which integrate project and business processes.

We see this with the trend in recent years toward ‘Enterprise’ or ‘Corporate’ project management offices. These aim to address integration issues associated with the functional silos of the large organizations, or to align projects to business strategy, or to provide visibility on project spending and achieved value through various reports and dashboards. Many provide support publishing policies, procedures and guidelines. Others manage the project life cycle and integrate this to the system development life cycle, or to other key business processes linked to change and change management. Yet others fashion themselves as the center of excellence and central point of contact for the business. Still others focus only on staffing PMs or on financial reporting or vendor management.

Some try to do it all! But realistically can a single PMO do it all?

Well not unless it’s very mature. Not unless the business it supports needs it to.

Recently I’ve come across another model. It’s presented in a book titled The Complete Project Management Office Handbook, by Gerard Hill. The model in the book presents a comprehensive look at the project management office competency continuum. It presents the PMO and related functions and concepts with a pro-business slant. The book details over 20 functions and functional areas, which collectively comprise the competencies an organization may choose to support in their PMO.

What I like about Gerard Hill’s competency continuum is that it reminds us, first, that alignment of project activities to the business objectives is essential to ensuring that projects deliver value. Second, that to be successful a PMO must do a good job at whatever set of functions it performs to support the organization. And finally, these functions must help assure projects deliver that value which is required for the business to meet its objectives.

 

Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]