Project Management

Sharing tips in developing team work plans

on Thursday, 20 March 2014. Posted in Project Management, Blog

Sharing tips in developing team work plans

 The project manager determines whether any project management activities should be included in the team workplan. Be specific when defining the skills, background, and experience required for each task. This allows you to make more accurate work assignments (role) to team members and minimizes problems caused by assigning a team member to inappropriate responsibilities.

·          Do not create artificial contract deadlines that are actually target dates. Dates that are deadlines should be specified in the contract. Dates that are not in the contract are typically target dates, which are objectives or goals that may move.

Critical Path Versus Critical Chain Approach

·          Workplan development follows either a Critical Chain or a Critical Path method.

-       Critical Chain Approach—Focuses on the final deliverable due date for the project rather than on interim due dates. Activity durations are estimated with no safety factor or time buffer included. Instead, Project Management incorporates safety into the Workplan to protect the final due date.

-       Critical Path Approach—Project duration is driven by the interim activities that must be completed, the availability of resources, and safety factors built in to each task or activity.

·          The Critical Chain approach is concerned with the latest date that a task or activity may be started to meet the final due date of the project. 

·          In the Critical Path approach, a project start date must be determined. If a start activity is not obvious, create an activity entitled "project start" or "initiate project" to indicate that the project does have a real start time. 

·          In a Critical Path approach, resource availability affects the duration of tasks, milestones, and the overall project completion date. The more resources available, the shorter the durations. In the Critical Chain approach, the required completion date determines the resources required. If resource availability is limited, the scope of work must be re-evaluated and possibly reduced to meet the completion date. In either case, the resource model is updated to reflect actual resource assignments.

·          In the Critical Path approach, identify activities that can begin immediately (that is, they have no predecessors), and make the start activity their predecessor.

·          Using the activity list and dependency information, sequence the remaining activities. A simple activity-sequencing example is shown below.

Activity Sequencing 1

Activity ID


Immediately Preceding Activity


Project A



    Initiate project



    Assign project manager



    Establish constraints



    Develop project schedule

3, 4


    Prepare estimate expenses

4, 5


    Assign resources

5, 6


    Distribute project documents


 ·          The same information is presented in the Microsoft Project example, as shown below; however, Microsoft Project automatically draws the precedence diagram.

Activity Sequencing 2


·          Identify the finish activity for the project. For example, include a milestone called "project end." Every activity in the project needs to be completed before this milestone is reached.

Workplan Standards and Guidelines

·          Review any guidelines, practices, or procedures for preparing a Workplan. Verify that the WBS is in line with the Project Charter, and update sections of the Project Charter as necessary.

·          The baseline Workplan and framework documents for the standard methodology can be used as a starting point. Also refer to any lessons learned documents and other, similar workplans. Expert advice or opinion is also valuable when performing this step.

Workplan Review

·          Workplan development is an iterative process because the resulting schedule needs to be compared with the scope and other constraints to verify its feasibility.

·          The Workplan should be reviewed frequently. The best project managers continually try to assess what can go wrong and perform up-front analysis on the schedule. Clearly, project constraints and objectives can change; therefore, schedule analysis should be an ongoing activity.

·          Obtain Workplan buy-in from all key team members. In many ways, this is more important than formal approval, because team members who are committed to the Workplan are more likely to put forth the effort required to adhere to it than those who are not.

·          Review of deliverables includes reviewing action items and verifying actions to improve performance, revisiting and refining the Workplan, and acknowledging that the plan meets the expectations of the management team.

·          Reviewers should typically include the project sponsor and the organization. They may also include other organization authorities who have direct influence or need-to-know responsibilities. Reviewers can vary from project to project but should be determined early in the project life cycle.

·          To avoid delays in the overall project schedule, the time allotted for reviewing the Workplan should be formally communicated to the project sponsors before submission for approval.

Please share your thoughts and tips on workplans 




Scheduling an Oracle project - Is full schedule really needed or we should use only "good-enough"?

on Tuesday, 01 January 2013. Posted in Project Management, Blog


I faced two models in general:


1) Full scheduling (requirements--> PBS--> WBS --> schedule) as it is taught in ERP training.


2) Only generic name of basic tasks, responsible, deadline (Most top consulting companies use this pragmatic approach for their implementations, upgrades, etc…


I find that keeping the scheduling process as simple as possible works best.

People who do not fully understand PM terms can be intimidated by such terms and this can lead to difficulties.

In my view point, a fully detailed schedule for the entire project is usually pointless because the level of uncertainty is too high to be of any real use.

Best practice is to divide the project into stages (or phases.) and produce a detailed schedule for the current stage, with an outline schedule for the rest of the project. This gives you the detail and accuracy to effectively manage the tasks at hand, and also the long-range forecast for delivering the entire project.

One of the tasks in each stage is to produce the detailed plan for the next stage. This is the real pragmatic approach because you are only putting the effort into a detailed plan when you need to, and when the level of certainty is as good as it can be.

Personally, I use placeholder tasks early on the in project - e.g. having a Transition stage which contains various testing, training and deployment summary tasks. Each summary task has a subordinate task called "placeholder" which has an estimated duration. This ensures that anyone reading the plan is clear that the detailed planning has not yet been done for that stage, while still providing some indication of the likely duration.

Most new methodologies follow this approach (Agile, Accelerated, FastTrack, etc..)
These approaches advocates "phases" called "Releases", a 3 month period in my world that enables me to set a meeting schedule, deliver a fairly accurate list of things that will be completed within the Release and discuss "Team Capacity" of the individuals involved taking into account vacations, other commitments, etc





How important is teamwork on a project

on Tuesday, 01 January 2013. Posted in Project Management, Blog

In my experience teamwork has been an important aspect of the success for our projects, I have been lucky not to be involved in any ERP failures. No matter how good you are, the success of any COTS (Commercial off the shelf) application is a team effort.

 By using simple words like we, us, team the motivation and implication increases two folds.

Good ideas come from many areas, details that you may have missed may come from different perpectives or team members.

Also implicating and mixing functional and technical individuals in the same meeting may get the ball rolling on out of the box thinking or critical issues that may not have a straight answer.

Project success = Teamwork and Managing Change


Methodology for project delivery success

on Tuesday, 01 January 2013. Posted in Project Management, Blog


In my experiences, you must evaluate 3 important points before selecting a methodology for your project. 1) Organization maturity meaning clear project definition and repeatable project processes 2) Resistance to change 3) Project size and business impacts


In my career, a methodology is a structured approach for project delivery; in the 1990’s we were talking about XP (Extreme programming) it faded a bit, but has made resurgence lately with agile gaining momentum also very popular in those times was prototyping. Early 2000’s, Sigma Six, ITIL, CMM and Waterfall became very popular.


I was asked the question which methodology would you use to increase your probability of success.

My definition of project success is defined as getting the project built on time and on budget. 

Failure from a management perspective is based upon exceeding initial budget, exceeding initial schedule, or not completing initial scope.  

Also Failure from a business value perspective is when the cost of the project exceeds its benefits. Usually, an ROI or a TCO is done based on a defined time period. I have not seen many organizations ever bother to measure actual return following deployment but this practice seems to gain popularity.

We always assume that we have an A team, the answer is not "agile " vs. "waterfall" development -- some experts like one, and some like another method. Organization maturity, clear project definition and repeatable project management processes often have much greater impacts on product delivery success.

While experts differ on the best software development method, most would agree that successful projects share the following characteristics (mentionned in the project survival handbook):

- project is approved and funded
- project has a business sponsor
- project has an IT sponsor
- project has clear objectives
- requirements are clearly written
- requirements are traced throughout the project life cycle
- key stakeholders are involved, and kept involved, throughout the project life cycle e.g., business, operations, subject matter experts, software end-users, etc.
- project plan is defined and adjusted as needed (see change management below)
- responsibilities are clearly defined
- people are held accountable for certain activities and deliverables
- project documentation is prepared
 project risks and contingencies are defined
- communication and training occur at various steps of the project life cycle


Do not get bogged down which methodology you should use they all work, just make sure which one fits the best with your organization maturity and structure, the most important aspect do not expect any major difference on the project outcome when selecting one methodology over another.




7 greatest challenges you can face on your consulting project

on Tuesday, 01 January 2013. Posted in Project Management, Blog


Every project comes with some baggage here are some challenges you may face on your project:


1. Setting good customer requirements, project expectation by balancing cost, quality and time. This usually centers on the client requirements communicated but the usual issue is what he has not communicated.


2. Getting the team motivated usually not a problem but when it becomes an issue, projects may miss their deadlines.


3. Managing change throughout the project, scope creeping and project changes must be handled in a systematic fashion.

4. Communication issues – misinterpretation, email, verbal


5. Non-constructive work environments

6. Finding the right balance between when to make decisions democratically and when to simply make the decision yourself

7 Defining clear metrics for project success (deadline, implementation, cost…)  


The Critical Scoping and Planning Phase

on Tuesday, 01 January 2013. Posted in Project Management, Blog

The initial phase of any scoping project must be well understood and organized. Here is how I would approach a new scoping and planning phase for ERP, CRM or EPM project.
Do not hesitate to email me your feedbacks or call me to discuss 

Project Management Keep it Simple

on Tuesday, 01 January 2013. Posted in Project Management, Blog


Simplify your project manager and program manager position within your organization.

Companies in my humble opinion have misunderstood the role of project managers and program managers.

Stop the buzzwords and keep it simple, a project manager manages a specific project to create a product or a service which brings some added value and a program manager oversees multiple projects that lead to improvements within the organization.

The important point to master is How to manage multiple projects? 

The approach that works best for me is to start a project inventory within the system you use. That way you can track the feasibility study, proof of concept, cost/benefit etc, and right from the start. I think it is imperative that all stakeholders face reality. Otherwise you as a project manager get blamed for not meeting fantasy objectives, and you stress over other people's unrealistic objectives and fantasies. It takes some sitting back, away from the immediate fires, to evaluate the demands and resources available to meet project objectives


I even have a project called prospecting where I track the time and the feasibility of these projects. This approach helps me plan projects that actually become reality. Try it and send me your feedback.



The top 5 most critical communication skills for a Project Manager are:

on Tuesday, 01 January 2013. Posted in Project Management, Blog

1. Effective writing - using clear, unambiguous, non-threatening, commonly understood English (the technical language of business worldwide)
2. Listening - not just hearing but truly listening to what the speaker means
3. Compassion/Empathy - being able to manage a project team while at the same time being empathetic to life's incredible unplanned "emergencies" that crop up when dealing with people
4. Passion and enthusiasm that inspires the team to row the boat all in the same direction.

5. Avoid always being status quo, during any enterprise project you must stand your ground and take decisions that you believe is in the best interest of your project. (Avoid Group Think sometimes its hard and usually creates costly overruns)

Really a combination of all the above mentionned is required  but  demonstrating your passion in effort and  quality will garantee a great team approach and may create a high performance team.

A Forrester  study states, 60-95% of defects in delivered interfaces can be traced directly back to poor requirements, and 40% or more of a software developer's time is spent doing rework. Use a prototype approach or methodologies like SCRUM that forces both parties to speak to each other at a regular shorter time interval.

Tips for Enterprise Production Cutover Projects

on Tuesday, 01 January 2013. Posted in Project Management, Blog


What is production cutover?

Production cutover is the transfer of the Enterprise Project solution from the project team to the business.  It starts with the creation of the production instance the phase will close following the first month end transacted on your erp/crm (EBS, , Siebel,PSFT, JDE,...) 

This is where you initiate your planned recipe for cutover week:

Example of statements that should be included: No Legacy systems will be available during cutover week except for the Payroll process.  

You should also outline the manual transaction mechanisms that will be used to capture and maintain business operations if any systems remain operational.

The production cutover plan, outlines all the process steps and manual procedures/activities to be executed in the migration of Legacy systems to Oracle, also identifies and assigns resources and management to each control process , including sequences of all tasks using linked dependencies to set dates for deliverables, and identifies and integrates all other points of coordination.

Tips: One item that is usually overseen is task duration, we all tend to be optimistic add some slack, the point the longer you take to perform your task the more pressure is added to your colleague, and make sure you check all dates on your plan, in most cases an enterprise wide implementation takes longer than a day.

Here is a high level flow of production cutover team diagram:


Be very careful that all transactions are accounted, workflows complete (as much as possible), payments complete. Review cutover best practices for more detailed advice (ping your consultants, they’ve done this before). If you don’t do this you will hit serious problems.

Cutover is a stressful time no matter how well planned. The Project Manager should ensure everyone stays calm, ensure work is balanced and avoid burn-out for those working shifts. Organize some food during the cutover, step in to calm any friction quickly and monitor every last aspect of progress.


Four ways to avoid competing on price

on Tuesday, 01 January 2013. Posted in Project Management, Blog

Who do you think is the low-price leader in retailing?

Once, the quick answer would have been Wal-Mart. But here's a cautionary tale of what can happen when you compete on price: A new study from retail consulting firm WSL/Strategic Retail shows 88 percent of customers no longer believe Walmart has the lowest prices.That's got to hurt, given how much time and money the retail giant has spent on pitching its "always low prices" slogan. It's also likely painful for Wal-Mart's vendors who've often strained to get their costs down to fit into Wal-Mart's super-low price narrative.

Where do customers think prices are cheaper? The Internet, as well as other discount retailers and grocery stores.

Given this changing perception, competing on price is even less attractive. So how can you avoid it? Here are four tips of my own:

1. Benchmark. Find out where you stand on pricing compared to other companies in your industry. Its possible competitors have raised prices while you’re stuck to the bottom.

2. Develop unique products. It's best to offer products and services that are unique to your company. The reason is, when competitors hold sales, you won't be similarly forced to cut prices because your offerings can't be price-compared. Be specific

3. Bundle your product with services. Take a look at how Jonathan Fields has bundled his new book, Uncertainty, with his consulting. No discounts here. Bet they're selling like hotcakes. This is my favorite if I ever write another book; I will follow a similar approach like Jonathan.

4. Build your reputation. When you're known as the best in your industry, price isn't a problem. Clients expect to pay you a premium. Get client references, video testimonials, or at least ones where you can use customers' pictures next to their endorsement -- they're highly impactful in helping clients envision themselves using your product.

Pricing is a key factor in marketing and selling your product or service.   Whatever price your choose, make sure that you have an end objective in mind and that your pricing strategy supports your end objective.

Never compete on price, unless you have a cost advantage that is near impossible to duplicate.  Competing on price is almost always a losing proposition.



As the PM, Always give away the wins, most important tip I can give to anyone

on Tuesday, 01 January 2013. Posted in Project Management, Blog


One thing that I learned throughout my career is the importance of teamwork. Human nature is complex and one of the areas I believe I have done extremely well from employer feedback is my self knowledge:

how you respond to conflict, what motivates you, what causes you stress, and how you solve problems and how to adapt your own style to get along better with others

Having been to many corporations because of my profession, one key mistake that is made often, most people hire in a tribal way. They recruit people like themselves; people they feel comfortable with and who they know or have worked with before. But to hire well for your project to be successful.  You should seek out diversity, diversity of thought, people who bring different ideas, experiences, and perspectives to your organization, expecially on difficult enterprise wide change projects like CRM, ERP and SAAS projects

Now, here’s my methodology so you can do this, too:

  • Let go of judgment. The first step in recognizing talent is recognizing talent! You can only do this if you are able to put aside your own issues and prejudices and see others for who they are. You’ve got to be able to compensate for your own “perceptions” when assessing others.
  • Let go of jealousy. If you’re jealous of what they’ve got, you’ll feel it, they’ll feel it, and it will end bad.
  • Let go of labels. Strong people don’t need anyone to define a relationship with labels because they’re able to figure it out on their own. Trying to label a relationship can scare a strong person off. (If you’re not comfortable with ambiguity? Keep that to yourself.)
  • Let go of doubt. Great people want people around them who are even better then themselves. If you don’t believe you belong, you don’t belong.
  • Let go of control. Great people will do things you don’t understand and can’t explain. Insisting on living in a world you fully understand will keep you from experiencing people who can open you up to new and bigger ideas. Great people approach their worlds with innocence, wonder, and curiosity.
  • Let go of you. Help the people around you shine brighter. The strong one’s will keep you around and start feeding your gift back to you. (The weak ones will show their true colors by trying to take advantage—easy to deal with once you’re prepared for it.)
  • Let go of safe. Surrounding yourself with extraordinary people guarantees one thing: change. Scary, risky, life-altering change. No-more-comfort-zone change. Great people require us to abandon the safe harbor of our routines.

Did you get it yet? Greatness happens when you let go. It’s the ultimate “chicken soup;” you bring only your true self and all the other ingredients you think you need actually are provided by others when the time comes. It takes an incredible amount of self-confidence and faith to play this game—but I never did say it was easy.

That’s my recipe. I hope you can make it work for you!



Is Agile mainstream and which methodology to use when using Business Accelerators

on Tuesday, 01 January 2013. Posted in Project Management, Blog

 -----Original Message-----
Sent: August 16, 2012 3:37 PM
This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: 2 Questions

 Hi Alex, 

I am a regular reader of your blog and I work as you can see from my email address at a large S&P 500 company, I am having this debate internally on Agile methodology what's your view is it mainstream? 

Second question we are implementing Business accelerators with OUM 5.4 methodology which methodology should we use and why (As you see they are 2 Large Consulting Firms)? XXXXXX consulting firm is telling us the full Lifecycle Technology view and the other XXXXXX consulting firm is mentioning Solution-Driven Application Implementation View 



People often believe that they are the few that use a methodology like Agile, I am in the camp that there is broad awareness of Agile, most of the S&P 500 companies have jumped on the Agile trend, but most don’t perform the end to end Agile methodology mostly because of the nature of their business.

Some do standing morning scrums, other use user stories for testing, others use regular pre-planned sprints,  others customize the roles of scrum master, chicken and pigs.  I think Gary to answer your question almost all of us cherry pick parts of the agile methodology to fit company culture and implement some type of Agile Methodology.

Yes I believe the Agile methodology is mainstream and has been incorporated in lots of consulting and recognized IT methodologies, but way overused by management as a buzzword, I think this trend of implementation methodology buzz will be fizzling in the near future. 

To your second question: OUM (Oracle’s Unified Method) is the new version application methodology that replaces Oracle’s AIM methodology.

The answer is straight forward in your case you are using Accelerators you should use The Solution-Driven Application Implementation View this provides support for implementing commercial-off-the-shelf (COTS) packaged application products, or product suites, such as Oracle E-Business Suite or PeopleSoft Enterprise, JDE etc. This view reflects a solution-driven approach to implementing packaged applications that leverages a pre-defined business solution (like Oracle Business Accelerators) as the proposed business solution and tailoring that solution to the client's specific requirements during the project.

The Technology Full Lifecycle View provides access to the material required for full lifecycle technology projects. This view provides support for custom development, fusion middleware, and technology implementations. More for focused custom development projects.


ZOO Comment

Copyright 2018 All rights reserved.