<-- LOCAL CSS -->

banner_stats



Lessons learned from a cross-functional project &ndash; both the agony and the ecstasy

Contributor: Alex Orlov
Posted: 06/10/2013
Lessons learned from a cross-functional project &ndash; both the agony and the ecstasy
Rate this Article: 
5
Average: 5 (1 vote)

Whether it’s the difficulty of getting everyone to agree on the project scope or having to contend with multiple stakeholders, cross-functional projects throw up a particular set of challenges. Contributor Alex Orlov describes the agony and the ecstasy involved and what it took to overcome the challenges.

One day in February 2012, while I was working as a Process Improvement Consultant, I was informed that the General Services team’s travel department needs a Travel Desk application. As the cost pressures were high, we were advised that we should not look at obtaining off the shelf products and we should develop a solution internally. Thus, the project hovered around understanding the current process, identifying business requirements, documenting them, developing application prototype and finally rolling out the new application as per the newly designed process.

Managing a cross functional project throws up a particular set of challenges

Initially, the project looked very simple. Employees who had to stamp their travel visas or who had to travel for business, filled out a form, got it signed by at least 2-3 authorities and then submitted the application to the travel desk for further steps. We only had to automate the process.

Unforeseen hurdles (the "agony"):

In just a few days of initiating the project, we realized that the project was not as simple as it looked. The project was cross-functional. It involved individuals from different departments. It did not have a single owner/sponsor/champion. The scope of the project was also unclear.

In Project Management, "Scope Creep" is a well-known issue and I was worried this project would be a classic example of this. The project also faced a challenge of resource crunch and an overburdened project lead.

Additionally, the project turned out to me more complex than we thought and we had to determine an appropriate approval process which meant adding additional work for senior management. This also had to be acceptable to the stakeholders.

Some of the difficulties we encountered:

Getting the Project Lead to commit time to the project

The travel desk was managed by only one individual and she was also playing the role of a project lead. With the dual responsibility and heavy workload, we found that she struggled to prioritize the project over her other commitments.

This was an important issue as her involvement was integral to the success of the project. To tackle this, we requested the Admin owner (General Services Director) to include successful completion of this project in her annual targets for the year. As soon as the goals were modified, we observed the reluctance of the project lead changing into keen interest. What a change!

Identifying the project champion/sponsor when creating the project charter

The project lead and I (project manager) created the project charter. We did not face any challenge in creating the Business Case, Problem Statement, Goal Statement, setting milestones, among others. However, we faced a major challenge in identifying the project champion/sponsor and scoping the project.

The most logical solution for identifying the project champion was the owner of Admin department (General Services Director) but he may not have been the only approver of this project. This was because the application was mainly used by a number of users belonging to core operation teams and some of the major shared services functions such as Finance, Training, among others. Thus, Operation Directors and Shared Services Directors would have been the right choice of being the sponsor along with the Admin owner.

The project team internally decided to propose the sponsors to be three operations directors, the admin owner and two directors from Shared Services functions. However, the question was "Who will bell the cat?"

To tackle this challenge, it was very important to take the buy-in of organization’s CEO. To get this, we created the business case which showcased its impact on the organization holistically. We described the total number of days required to just approve one travel request and named this time as Non-value added time. We calculated the Process Cycle Efficiency, i.e. the value added time of approval process divided by total time required to complete a travel request. It gave startling numbers which were music to our CEO’s ears. It took about 10 days to approve just one travel request. Wow!!

Our presentation to the CEO was successful as we promised to reduce the 10 day approval process to just 2 days; we then shared the challenge of having limited stakeholders and accordingly proposed our sponsor list. It just took a few phone calls for the CEO to accept our proposal and our project had the blessings of each proposed sponsor.

Scoping the project revealed conflicting interests

As this was a cross-functional project, each department had its own interest and requested some features in the application that would reduce their manual work. These conflicting interests derailed the core aim of creating the application for reducing the approval process timeline. Thus, the project team got together and created a phased plan for developing the application. Accordingly, we were able to meet demands of each department and also were able to focus on core business case.

Identifying the right subject matter experts for gathering requirements

The first month was involved in creating the project charter, setting the scope of the project and getting buy-in from all stakeholders. Now came another challenging part of project which was Requirement Gathering. The key problem to address was who would be the right subject matter expert helping in requirement gathering. As employees from many different parts of the organization needed to travel, the project team was not able to effectively identify on who would give all the requirements. This challenge was tackled by looking at the data of travelers. We chose those subject matter experts who were frequently involved in a lot of travel and had to go through the manual process overtime. The Governance committee (comprising of proposed project sponsors) approved the list of subject matter experts and we completed requirements gathering exercise with them.

Creating the application and completing the project

After we documented the requirements, the application development team worked on creating the prototype proof of concept (POC). This was tested by the subject matter experts. Following testing, the application was rolled out across the organization.

Key Takeaways:

Here's what I learned about overcoming some of these challenges:

#1: Incorporate a common project goal to overcome conflict of interest among project team members

As different individuals from different groups are involved, we face conflict of interest among project team members. The appropriate way of tackling this situation is to incorporate a common project goal in the annual targets of these individuals

#2: Select appropriate project sponsors from all involved departments

A project sponsor from only one group may lead to inclusion of bias and tilting the project benefits to that respective department/group. It’s better to include the right project sponsors from several appropriate departments. To complete this effectively, the team has to create a strong business case and should be able to sell it to the organization making the top management know the importance and need of the project.

#3: Define and agree the project scope with all key stakeholders to avoid "scope creep"

Scope creep is a well known issue where the scope of the project keeps changing across its lifecycle. The only way to ensure that scope creep challenge is met is to spend an appropriate amount of time defining the project by discussing and finalizing the project scope from all required parties. Documenting and seeking approval on finalized project scope.

#4: List resource requirements in your project plan to identify and mitigate resource contraints

Resources are always limited for all organizations. Hence, it is important to use them effectively. Resources could be in the form of man-power, applications, machines, among others. A strong project plan listing the requirements of resources in the most detailed way followed by seeking those resources from project sponsor is the best way to tackle resource crunch issues.

#5: Communicate the WIIFM factor to get the project lead on board

As change agents, project managers should be able to pick this trait of project lead quickly. Accordingly, they should motivate the leads to perform effectively. Motivation could be done by either discussing WIIFM factors with the project lead (WIIFM stands for What’s In It For Me) OR seeking help from his/her manager to get the act going.

Concluding Comments (the "ecstasy"):

  • The application revolutionized the travel approval process
  • It reduced the cycle time from 10 days to a mere 2 hours
  • Breakthrough solution achieved in limited time of 2 months

This being achieved, the other day I was in the Executive Committee meeting and one of the Directors told me that the travel application is not of much use for him as he has to keep approving the travel requests... Phew!!! I just responded, "Phase 2 of this application will provide a facility to delegate your job to your Executive Assistant."

This reminds me of the KANO model: The exciting features of a product at the time of its launch, may become the not so exciting features after some time. Hence, we need to keep evolving and improving with time.


Thank you, for your interest in Lessons learned from a cross-functional project – both the agony and the ecstasy.
Alex Orlov
Contributor: Alex Orlov