Project Management Process and Tools Can’t Be Too “Big” for Small Projects

While browsing through the latest edition of PM Insider*, a newsletter from ProjectManagement.com, the following question and correspondence caught my eye.

Question:

I have a short project coming up that seems too simple to need to go through all the usual processes. Is there a quick way to ensure that the project plans are baselined and tracked in my automated software? My boss will still want(s) effort, schedule and cost captured and reported and the usual PMI processes honored?

 Provided Answer:

A. Collect cost receipts in a manila folder and ask team members to write down the time they spend on each task. You can figure out a report at the end.
B. Go through all of the steps, including your automated software files, just as you usually do. Short projects should be planned, documented and archived exactly as longer ones.
C. Use a quick plan with lighter documentation, but involve your team in close communication on a daily basis.
D. Pull a similar electronic project file from your archives and change its name to the name of this project. Submit this disguised project at the end.

This is a great question and evidence of an endemic issue for many project management professionals, which is really – my project management process and “automated software,” be it PPM or something lighter, is clunky or actually “not automated enough” so it’s a hassle and feels like a waste of time to go through and use for “minor projects.”

I concur with the sentiment of the answer provided that if the project – major or minor – is worth doing, then it’s worth tracking, which means the investments you’ve made in project management processes and tools should be leveraged to do so. And if those tools and/or processes make it overly cumbersome or time-consuming to do this for minor projects, then the process and/or tool(s) should be adapted to accommodate managing smaller projects easier.

A 200 hour departmental project should be easier to manage than a 20,000 hour enterprise project. That’s intuitive enough, but not always the case when processes and tools have been designed and implemented to manage, track and measure high investment projects. If employing the same processes and tools to manage and track smaller projects makes it unnecessarily complex and time consuming, is it really worth it?

Hello rogue projects.

Hello bad habits.

Hello failed investments in project management process and tools.

Processes and tools should be flexible to accommodate this delineation without sacrificing management capabilities or tracking requirements. If it’s too much work, it probably won’t be done if the perceived value/return of using the process/tools doesn’t correlate with the scope of work or time required to manage a seemingly minor project.

 

*ProjectManagement.com Newsletter 12/4/2013

Daptiv honored as Bronze winner in the 5th Annual 2013 Golden Bridge Awards

 Only Project Portfolio Management Vendor To Be Recognized In The Mobile Product Innovation Category

This month, Daptiv earned the Bronze status in the Golden Bridge Awards for its Daptiv Mobile solutions. We were the only PPM vendor to be featured in the Mobile Innovation category. More than 40 judges from a broad spectrum of industry voices from across the world participated and their average scores determined the 2013 Golden Bridge Business Awards winners.

The annual Golden Bridge Awards program encompasses the world’s best in organizational performance, innovations, products and services, executives and management teams, women in business and the professions, innovations, case studies, product management, public relations and marketing campaigns, and customer satisfaction programs from every major industry in the world. Organizations from all over the world are eligible to submit nominations including public and private, for-profit and non-profit, largest to smallest and new start-ups.

Daptiv Mobile makes it simple for enterprises to deploy and for project managers and team members to use. Since Daptiv Mobile leverages HTML5, there is no application to install or maintain. Daptiv Mobile is accessed on the user’s smartphone browser and the application automatically syncs any updates and changes made on a mobile device with Daptiv PPM. Unlike other mobile PPM offerings that are iPhone or Android-specific applications, a single version of Daptiv Mobile caters to clients across multiple mobile platforms – including iOS, Android and Blackberry. This ensures that users experience the same interface across multiple devices.

Daptiv Mobile, a HTML5-based Web client that enables users to securely manage timesheets, tasks and approvals anywhere from a mobile device. This application complements Daptiv’s cloud-based PPM solution and gives users more choices on how to use Daptiv PPM away from their offices and computers.

To learn more about Daptiv mobile, please visit: http://www.daptiv.com/products/daptiv-mobile.htm

 

Implementing and Monitoring Organizational Change: Part 3

While its relatively straightforward to monitor the performance of a risky technical component, track defects, and make a binary “go” or “no go” decision as to whether that component can be used,  monitoring and controlling the effectiveness of organizational change activities are often more difficult, given their emotional and typically subtle nature.  How do we know that individual employees are accepting the change or are we about to experience a mutiny?  How do we know that the impacted organizations have been able to adapt and accept the changes, or are the supporting roles, processes and procedures going to undermine or undo all of our efforts?  How fast can we expect a change-averse culture to change?  How do we know if we’re going too fast? Can we go faster?

The solution is the same as for the technical component; we establish a monitoring mechanism which tests the response of the impacted areas against the desired result.  The big difference is in how the monitoring and measuring is done.  In the case of the technical component we establish a performance standard and collect empirical data which measures performance against that standard.  If the standard is met we’re in the clear, if not it triggers a contingency plan.  With organizational change both the performance standard and the data collected may be more qualitative and subjective but it still serves its purpose; determining if there is (or is not) a problem and if a problem does exist, doing something different to influence the outcome.

For example, consider the project where the first indication that training or change management were not successful is when a major business process (like billing or payroll) cannot be executed?  Clearly we need ways to identify and implement course corrections long before they reach the critical stage of final implementation. 

Issue Log Monitoring

One approach to monitoring is to use the project issue log or create an additional log  for concerns; items which are not immediately solvable or actionable.  Assuming that the team is diligent in reporting organizational change related issues or concerns, the frequency and severity of issues can signal a developing problem, especially when sudden increases are observed in a single area.    If the team also compares the issue and/or concerns log with the risk register, which has clearly identified organizational change risks, certain elements in the logs will stand out and can be interpreted as increasing risk probability or trigger a contingency plan.

Surveys

Surveys or questionnaires to monitor critical elements associated with organizational change provide a more structured approach to monitoring organizational change risks.  In this approach the project team creates a survey designed to elicit feedback from the organization about its perception of the project and the organizational change factors which may contribute to the success (or failure) of the effort.  By conducting the survey at regular intervals and comparing result from survey to survey, the team can quickly identify areas which require more attention and intervention.

  While creating and administering a survey represent additional time and cost to the project there are a number of benefits to be considered:  1)Collecting this information forces regular and systematic review of the project as it is perceived by the impacted organizations, 2)  As the survey is used from project to project it can be improved and reused, 3)The survey can quickly collect feedback from a large part of the organization, increasing the visibility of the project and reducing unanticipated or unwelcome reactions. 

Conclusion

In conclusion, organizational changes and the management of those changes can be a critical component for project success.  While the discipline of organizational change management may not be the primary focus of the project,, attention is required to understand what organizational changes may be required and their impact to both organizations and individuals.  Understanding the nature and scope of these changes enable the project team to more effectively plan, execute, and monitor their execution and effectiveness. 

Introducing and Setting Up a Project Management Office

In my last article we delved into organizational maturity for setting up a PMO; this article will deep dive into how to introduce a PMO without disrupting the established system. The first step is good communication–clear and complete information reduces confusion and eliminates resistance based on fear and conjecture.

Communicate the mission, objectives and purpose of the PMO. Be open and transparent regarding the decisions and activities of the PMO. Inform the enterprise of the reason(s) the PMO exists, what it will do and how it will bring value to the enterprise. Also, demonstrate how the PMO will be a partner and not a hindrance in working toward the success of everyone in the enterprise.

Once the need to set up a PMO has been identified and the communication campaign is actively underway, the PMO must be designed from the beginning to meet the specific needs and environment of the business it supports. Project Management Offices take on many roles depending on their mission and objective, hence setting up a PMO is not a short-term activity. It requires significant effort to complete analysis, design, planning, review and implementation. Cooperation and involvement from the business is essential to ensure the PMO meets their needs. Involving the business early and often by keeping open communication channels and soliciting feedback will allow you to manage expectations regarding the amount of time and effort required to set up a PMO.

Setting the priorities of the PMO
In order to move ahead with the planning process, the business should first set the priorities of the deliverables and services of the PMO. Next, assemble a planning and implementation team that includes stakeholders in addition to the PMO subject matter experts. In my opinion, business stakeholders must be involved throughout this process to analyze and take ownership of business needs and progress. On the planning side, it should be phased out, using a rolling wave approach as opposed to a “big bang” approach. These phases should be scheduled out using the roadmap model with detailed planning occurring at the initiation of each phase. This makes the planning current and more relevant to the prevailing business condition.

Laying down project management processes
The next major task is to identify processes and tools required to support the services and functions the PMO will perform. Depending on business needs and budget, an organization may either develop in-house tools or purchase tools from vendors to help streamline projects. Project management processes should be designed to guide the project managers in the performance of the project. PM processes need to be adaptable to meet the needs of any project. A simple project with little risk may require a very light application of the process, whereas a complex project or a project with high levels of risk will necessarily require a more rigorous process.

Project management processes are generally based on standards or best practices such as PMI’s Project Management Body of Knowledge (PMBOK), PRINCE2 and agile. In addition to general purpose standards, organizations may also require and benefit from specialized project management best practices such as process improvement (Six Sigma), new product development and Go-To-Market.

Project Portfolio Management (PPM) is another function often found in PMOs. Organizations turn to PPM to manage their entire portfolio of projects, much like a portfolio of investments. In fact, projects are investments and companies expect to get the maximum return and benefit from these investments. PPM is the process by which they achieve this. Through project selection, project mix evaluation, portfolio monitoring and other activities, PPM is used to maximize returns on the portfolio.

Resource management (RM) often becomes the responsibility of the PMO because it is a natural partner with project management and project portfolio management. Within every organization there is a finite supply of resource types–including people, financial, and physical assets. Resource constraints affect both project work and operational work, the normal day-to-day work of the business. Accordingly, resource management processes should track the operational work (the day-to-day activities) in addition to project-specific work being done by the business in order to paint a complete picture of the total capacity or work an organization can truly deliver.

It is evident that these PMO functions are integrated and integral to the success of an organization. While organizations can adopt some of these elements, ultimately an organization needs to implement each of these disciplines to some degree to manage its program office effectively, even if they are being managed at different degrees of maturity. The project portfolio lifecycle encompasses elements of the project management process, the resource management process and financial management.

Keeping the PMO Relevant
To complete the whole cycle of project implementation and as part of a continuous improvement program, regular feedback from teams/project managers will help maintain the efficacy of the PMO at all times. It’s helpful to develop a continuous improvement program that includes:

  • Periodic reviews of the PMO objectives against the needs of the business
  • Measurements of the processes and tools such as effectiveness, adoption and consistent use
  • Identify areas for improvement

In the end, be sure to give new processes and tools time to be used long enough to overcome learning curves and to gather enough feedback and data to be able to make well-informed decisions. By their very nature, program management office teams are change agents. They institute new processes, implement new tools and may bring about changes in the way organizations conduct business. When planning for organizational change, the PMO must create conditions for change. Be aware of the politics of the organization, and build a base of support for change within the organization.

The third and final part of this series will touch upon metrics and how to measure success of PMO.

The Future of Project Portfolio Management – Perspectives from the Gartner PPM Summit

Gartner gave us an interesting look into the future of PPM this week, and projects as we know them may be left behind. I’ve been wondering about this for some time, as the pace of business continues to accelerate and business changes – represented by projects – are called on to deliver results faster and more frequently. But I’m getting ahead of myself.

Let’s rewind from projects back up the business stack for a clearer view. Gartner did this nicely from their opening keynote through their multitude of breakout sessions – many of which were standing room only. In this note I can only summarize the model, but I will delve more deeply into each area in future posts.

First, we must remember why we execute projects – to implement change in the business. Be it incremental improvements in efficiencies enabled by minor software enhancements, or transformational change in the form of a merger – projects have been our vehicle. Gartner rightly points out that the pace of this change is accelerating to the point where it is almost constant. Can the old annual planning cycles and waterfall projects really keep up with this pace?

Most projects today involve changes to some application system, as IT has become thoroughly embedded in most modern enterprises.  Techniques like Agile can continuously release improvements to these applications, taking in ideas for change and working them into a continuously prioritized stream of stories. And these stories – which represent useful business changes – can be released frequently. We are now talking weeks or months to roll out changes to applications, instead of years.

How to manage all those applications? Enter Application Portfolio Management. Much like managing a portfolio of projects, APM rationalizes and prioritizes applications. Andy Kyte (VP & Gartner Fellow) gave a dynamic presentation on APM for Executives that boiled this concept down to some simple truths. He reminded us that applications are really means to an end – business value. Using that as the goal enables us to make decisions not only about which apps should stay and which should go, but where they should reside. Do we really need all those systems in house, or would a SaaS or even a BPO model provide the desired business outcomes more efficiently?

This brings us to the top of the stack – business value. IT systems do not in and of themselves provide any value at all. So what does IT really provide? Business Capabilities! And here Gartner sounded an interesting new theme. Instead of seeing capabilities as just part of the EA stack, consider these like products. A SaaS shop like Daptiv, of course, delivers PPM capabilities as a product – and we see it that way. IT shops should consider that they are really delivering products like Purchasing Management, Workforce Management, and Strategic Sourcing. Viewing these as products allows IT to focus their efforts on delivering business value rather than just technology.

So now we see the full model being proposed by Gartner. It really uses some tried and true techniques from Enterprise Architecture and adds a few twists. We start with business capabilities at the top, which are now enabled by IT products – apps and supporting infrastructure to enable those capabilities. And we move away from simple application and project management to product management. And now that we have products to support, we implement a continuous change cycle – such as Agile – to ensure changes to the business outcome driven capabilities are implemented quickly and frequently.

The current pace of business is such that the old model has lost its usefulness and would leave us eating someone else’s competitive dust.