Category Archives: Project Management

How do we conduct business requirements (discovery) sessions?

Posted in Project Management by

During course of our consulting work, we have to engage with business users, both senior level executives as well as  individual contributors, to conduct discovery sessions to find out business requirements in order to either propose a solution or implement a packaged solution (Salesforce or Agile PLM,  in case high level requirements are already defined).

Finding requirements is always a challenging work. Based on our years of work with business users, we observed some patterns.  Based on these observations, we came up with a methodology to ensure consistency in the process.

We call it Listen, Synthesize, Present (LSP). Below is a description of each step in this process.

LSP

Listen

During this step, our focus is to interact with users to collect as much information as possible using various tools like interviews, observations, and documents.

Synthesize

Once we have required information, we process collected information,  validate it against multiple references. Validated information is then documented.

Present

Once information is validated and documented, we present it to all stake holders along with senior executives. High-level problem statement and solution is reviewed along with potential benefits.

Role of an external PM in PLM Implementation Projects

Posted in Agile PLM, Project Management, Uncategorized by

With two recent experiences (in fact bad experiences) of working with external project managers, I thought it is worth sharing my observations on this topic. By external PM, I mean a part-time project manager hired by the customer, other than primary implementation partner, to manage PLM implementation project. These observations apply to small to medium size companies which have limited resources to establish full-time PMO office and usually have small Document Control teams.

Companies hire external PM, primarily due to following reasons:

  •  They lack expertise/confidence to manage PLM projects
  • They don’t have capacity
  • They want to mitigate vendor related risk and involve third person to protect themselves against vendors

Before discussing external PM, let’s see what is really expected from a PM. He should be someone who:

  •  has long-term stake in the success of the project and gives highest priority to customer’s interests
  • is deeply involved in the project on day to day basis
  • understands the dynamics of the PLM implementation projects
  • can spare enough time/attention for the project

Whenever customers hire an external PM,

  •  It creates extra overhead in the communication. PM wants vendor to report to him/her instead of talking to primary project sponsors and users
  • In creates conflict of interest, remember vendors are interested in building long term trusted relationship with customer, they simply get frustrated due to this middle-man.
  • Due to part-time availability, PM can not engage enough with internal users, his/her availability becomes an issue.
  • Since PM is not a functional and technical expert (implementation partner is supposed to be expert) , he/she does not understand the dynamics of the project and focuses more on reporting aspects, meeting with deadlines, saving pennies, and justifying his/her role.

Instead of hiring external PM, what is recommended is to identify somebody internally in the organization to play this role. If internal person lacks prerequisites skills, he/she should be trained and enabled. You should look around in Quality, Engineering or Document Control teams to identify suitable person, someone who will live with project results for many years to come, not someone who will be out of the door in few months.

Remember, nobody else can take care of your interests except you.

Alternatively, if internal PM is not possible, then implementation partner should be trusted with PM role. Due to their prior similar experiences, Implementation partners can add a lot of value to the project by sharing industry insights. Clear expectations and success criteria should be set with vendor at the beginning of the project.

How to finish IT projects?

Posted in Project Management by

As IT consultant, we are much more excited to begin new projects as compared to finishing ongoing projects. In an effort to grab new projects, we end up losing low-hanging value in existing projects. Here are few thoughts to help wind up your projects.

As some one said, these are just my opinions, your situation may be unique, which may require certain adjustments in these activities.

How_to_finish_IT_Project

Delivering Portal and Intranet Projects Successfully

Posted in Project Management by

We recently implemented a corporate portal for a large retailer. By any definition, this was a successful project; project was completed within time and budget,  and business customer was satisfied about final product. Many factors contribute towards delivering a successful project, however, I would like to share two key practices that we followed during this project.

Engaging Business Customer:

Typically developers view business users as  someone they should avoid. Business user is viewed as someone who always keeps changing requirements or does not understand technology architecture and design. This is not to blame anyone because most of us go through same process during our professional experience. However, as we start working closely with business users, we realize that they are not as bad as we perceive them. They just explain whatever they do on daily basis. They expect consultants to suggest solutions to their problems.

In this project, we closely worked with business from day one. Our intention was to really understand their business processes, their specific needs, and work practices. Insights gained from this exercise were used to design new portal. During whole project and specifically during development phase, we had in-depth review of portal with business users  every two weeks. Objective of these reviews was to:

  • Understand business requirements as soon as possible
  • Validate each new feature by actually using it with business users
  • Keep business users on-board during every design decision and share its pros/cons
  • Build trust which helped us in lot of different ways
  • Keep communication channel open throughout the project

Believe it or not, we were able to control the project scope at every stage. All new ideas related to product features were discussed in detail and decisions were made to make sure that we select only those features which are feasible within  given time frame.

Short Development Iterations:

Our team has been adopting agile practices to help minimize project risks. Planning short iterations to manage development effort helped us in many different ways, namely:

  • It reduced the risk of building wrong thing
  • Output of short iterations became handy in review sessions with business users. Every two weeks, after each iteration, we had something to show to our business partners.
  • It served as a great tool to manage time and budget
  • Short Iterations became a decent tool for project planning
  • Individual productivity became very visible as everyone had to show his contribution in each iteration

There is nothing new about these practices. You will find tons of books which explain similar ideas under the umbrella of Agile Methodologies. Yet there is huge percentage of projects which fail altogether or don’t meet stakeholders expectations. I believe that Agile practices can help a lot to minimize project failure risks.  It is always challenging to adopt new practices and follow them on day to day basis.  I would recommend that instead of following any new methodology as per book, try to adopt few practices in each new project. After couple of projects, team would definitely see the value in new process and its practices.