Project Partners Blog

A constant need for Project based organizations is the need for their project systems to provide them with automated alerts for significant events in their projects execution. These events may have occurred during the normal course of business or may be upcoming.

Currently all parties involved need to troll through reports to find this information and this can be a time consuming process especially in high volume businesses. Oracle Family Pack M and onwards has taken a first step in this direction with the Exceptions functions in Oracle Project Management, but these are fairly limited in scale to what is needed.

The following discussion provides a framework for project based organization to implement automatic event alerts.

The requirements for this function can be listed as follows:

1. Capture different type of events as follows

a. Date based events: Upcoming/Past Due Task/Deliverable/Milestone Dates, etc

b. Financial events: Actuals a % of budget, Revenue accrual % of funding, etc.

c. Administrative events: New Projects being activated, Projects being closed, Bids awarded, etc.

2. Allow for user specification of events that need to be captured allowing entry of a benchmark (to be compared against: e.g., 80% of budget, milestone upcoming within 30 days) and also an additional benchmark for escalation.

3. For each event specified allow for defining a periodicity for the event that determines how often the system will check for the occurrence of the event.

4. For each event specify a list of people/roles that need to be notified and a separate list for escalations.

5. Email notifications to be sent out for events captured; to avoid email overload, group all event notifications by person, project, event type and send 1 email per person across projects.

In order to handle the execution of this function, it is envisioned that a batch process that runs daily will look for enabled events and check for their occurrence based on the periodicity defined. This is true for Date and Financial Events. Every occurrence of the event for all projects is captured in a holding object (table) along with a list of persons to be notified for the event. Once all the events are processed, the batch program groups events by person and additional grouping criteria as needed and sends 1 email to each person.

Administrative events cannot be handled by the batch process, especially if no history is maintained for the underlying data elements. In such cases, we can use functions like Oracle Alerts or DB Triggers to capture the events as they occur and store the information in the holding table. These records will then be processed for email notification along with other events by the daily batch process run.

Project Partners is in the process of designing such a solution for our clients. If you are interested in this function, please contact us.

That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try and respond to your comments, etc in future entries.

One of the biggest challenges that Project Managers (PMs) face in managing a project is weeding out mischarges to their projects. This issue is particularly aggravated in the following industries:

1. Construction industry:  Due to very thin margins on project work, any mischarges if not controlled and quickly reversed can wipe out the margins for the project
2. Any Cost Reimbursable type of contract particularly with the Government:  because these charges don’t get caught and then when they show up on invoices, the client starts disputing the invoices based on these mischarges, causing delays in payments and cash flow issues for the project.

The advent of Project Partners User Interface Applications ( a new product that allows you to provide Microsoft(R) Excel based user interfaces for 1 or more related project functions), has provided the ability to provide this critical function for project managers via an easy to use Excel interface for users of Oracle E-Business Suite Projects applications. The following section provides an overview of this solution.

An Excel worksheet will be setup that will allow Project Managers to pick their projects and specify expenditure types and the period for which they would like to review detailed charges.

All charges of the type specified (or all types) and in the current period will then be displayed to the PM with appropriate information for each cost transaction charged. The PM then has the ability to specify “Approved” or “Questionable” for each of the charges. Mass functions for both of these states will be provided to make life easier for the PM.

The screen will also filter out any transactions that had been previously approved by the PM.

This new Status field will be stored as a DFF against the Expenditure Items in Oracle Projects. A perdiodic (nightly) alert will be sent to the HelpDesk/IT/Project Accountant group if “questionable” transactions are found on any project. This group will review the transactions in Oracle’s standard Expenditure Inquiry screen and take appropriate action to research and either clear or transfer out the questionable charges. If the Transactions are cleared as being correctly charged, they are updated in the status field with a “Cleared” status and the PM can subsequently review and approve them.

An additional benefit of this approach, is that when invoices are generated and presented for review to the PMs, they can have a quick report (or another Project Partners User Interface Applications worksheet) wherein they can pull up any “Questionable” charges on the invoice and ensure that they are eliminated or cleared before the invoice goes out to the client.

This is a an example of how Project Partners User Interface Applications, combined with the expertise from Project Partners resources, can help you make life simpler for your Project Managers.

That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try and respond to your comments, etc in future entries.

To accomplish a successful business transformation project, experience, drawn from numerous projects over the years, has shown a pattern that is worth incorporating into every project. Successful projects establish a program framework and implementation approach that addresses the following critical success factors:

• Executive Sponsorship:  The project should strive to develop a productive relationship with the Executive Sponsors that encourages active participation in the project rather than a group that receives monthly status updates. The Executive Sponsors can be the greatest asset to a team and the most effective change agents if given the opportunity. Utilizing an effective decision making framework that facilitates timely decisions is a key component to leveraging the Executive Sponsor participation.

• Project Team Structure: The project needs resources that are perceived by their organizations as thought leaders. Many times staffing decisions are made based on availability and not necessarily on the candidates’ qualifications. Because of the importance of the project to the future of the business, there needs to be a priority given to staffing the project with the right resources.

If this is done:

• The ability of the end solution to meet the business needs is enhanced
• The organization has ready acceptance and confidence in the solution
• The time to develop the solution will decrease, which reduces the risks and cost of the project
• Business process changes will be sustained after the implementation is completed

• Rollout Strategy – A rapid and aggressive roll out strategy allows the project to develop wins and demonstrate benefits early. This will help facilitate a smooth rollout and cultivate a group of supportive users early.

• Change Management Program – As program complexity and reach increases so does the risk of not realizing the expected business benefits. Most organizations are resistant to change.

• Training Program – Firms often underestimate the amount of training required for successful transformation. How your firm certifies core system competencies and readiness will help reassure the users and their management that they are ready for go-live.

• Quality Solution - Many times clients have hired us after a failed implementation. The major contributor is often incomplete design or severe technical issues that had been overlooked during the testing process. The most successful approach to any business transformation project is to take a process focus to solving the business need and to view the technology as the enabler of the process. Focus on implementing end-to-end processes that are complete and meet the stated business objectives.Employ a rigorous iterative testing process to ensure that the solution will work effectively in a production environment prior to the implementation. Leverages these testing events to accomplish several key objectives: process validation, project team education, quality assurance and solution acceptance.

• Technical Support – Many projects with fewer complexities have failed or missed deadlines because of technical issues either at the infrastructure or application layer. Use a methodology that is process oriented. Technical competency as part of the team is a core strength you must have. Partner with the different technology vendors to ensure that their solution works and when it doesn’t, work closely with them to resolve the issue.

As your organization prepares to spend significant money on new tools to help you better manage projects, how prepared are you to achieve a return on this investment?   Bradford K. Clark confirms a 15% to 21% improvement in project execution and delivery costs in a 1997 study done at the University of Southern California by moving the project management maturity level up one level. William Ibbs, UC Berkley, confirms similar results in consulting and engineering firms.

Professional Services Automation empowers the Professional Services organization by providing a set of enhanced, automated and integrated capabilities to set-up, manage, control and report on client engagements.  The span of PSA includes the initial opportunity identification, through the proposal and planning processes, staffing and executing the work, collection of costs, recognition of revenue, invoicing the client, knowledge management and collaboration with both the internal team and the client representatives.  PSA provides a single end-to-end, scalable system to manage the professional services business. This allows for growth of the business, reduces response time during the sales cycle, allows the PMO to foster innovation and increases quality of projects, better management of consulting employees and subcontractor resources, and integrates intellectual capital management with the delivery of professional services.

There are four success measures for your PSA implementation: Revenue Production, Productivity Enhancement, Risk Reduction and Improved Cycle Times.  In all cases these should be valid measurement criteria to determine success and measure the ROI of your investment.  As you prepare to implement new tools for your organization, consider establishment of a baseline across your firm.  Assess where the organization is before you begin.  Leverage this knowledge to help focus change management and training efforts where the return will be greatest. Build a business case with specific targets and ROI measures.  Develop a plan to move your organization up the project management maturity level, implementing only functions and features needed for success. Plan training programs to increase the understanding and skills of your Project Management team, not just in the tools, but in application of the tools to better manage your projects.  Enable additional features and functions as your project management team matures.

Key Performance Indicators (KPI) can assist in assessing the present state of the business and to prescribe a course of action.  Real-time monitoring of KPI’s allows maximization of performance over the shortest time period.  Oracle Project Management provides hundreds of KPI measurements for utilization by your team.  Remember to be SMART in your use of these important tools:

Specific  Measurable  Achievable  Realistic  Timely

Plan on updating the maturity measurement of your organization on a regular basis to determine where you have been successful in your improvement and identify areas of opportunity for future improvement.

The Engineering, Procure, Construct (EPC) industry, in general, has struggled for years to find solutions that would enable integrated operation across the enterprise.  Manufacturing firms found several software vendors developing innovative solutions that allow the planning of material purchases, scheduling of shop floor activities and management of the distribution and logistic process all in a single integrated system that allowed enterprise level reporting and drill down to the underlying transactions that support detail analysis.  Part of this was due to pure numbers, with thousands of companies to purchase MRP and ERP systems, but only hundreds of larger firms to purchase EPC systems.  Niche players developed to fill certain gaps and larger firms developed in house custom applications to support their business.

With the evolution of ERP systems, the major EPC players have started to see solutions that are being developed for the professional services industry, which can be directly used for much of the engineering and design activities found within an EPC firm.  One area that the ERP packages have not addressed well involve the move from historic “standard cost” models used in manufacturing to the “actual cost” model used in some engineering and design work and most construction work.  Systems, such as JD Edwards, have offered an integrated solution between the ledger and payroll systems that allowed penetration into the smaller EPC firms but still relied on other niche and point solutions to provide the complete needs across the enterprise.  By building so much functionality into the GL database, firms with a large number of projects or the need to provide detail job costing ran into conflicts with the financial reporting needs of the firm since there was no sub ledger to off load the detail.  Other niche firms, like Deltek, developed a comprehensive solution for smaller firms doing business with the Federal government but were not practical for most commercial applications.  Firms like Niku and MPower targeted specific project driven needs and built solutions that did a fine job of meeting that specific problem, but did not integrate well into the enterprise view. Other firms, like SAP, sought to build “integrated solutions” by designing in certain aspects of the project management function but ran afoul of the large firm need for very powerful project management tools, such as Primavera, that were beyond the capacity they could reasonable afford to design in.

As engineering systems moved from the drafting board to the computer, systems were evolving greater ability to speed up design by defining various recurring equipment and design elements and relating these elements to specific purchased items.  This allowed the development of automated take-off capability and creation of purchasing systems that were integrated to the design elements and take-off lists.  While this made the procurement process more efficient for some types of projects, such as heavy industrial, it did nothing for civil and less “item” intensive projects.  Other point solutions were developed to aid these industries.  Intergraph and other design tool companies developed solutions to fill specific gaps, such as Marian.  Project management companies either built out additional offerings, such as Expedition from Primavera, or were acquired like Niku did with ABT or Primavera did with TeamPlay. Various niche players developed project-estimating tools, such as MC2 (MC squared) and others developed collaboration and document management solutions like Documentum and ERoom.  Companies, like Meridian, have built up solutions such as Proliance, Prolog and Project Talk for the industry.

As all these various solutions started to appear on the market, EPC, APC, E&C firms were besieged with solutions that did not integrate, did not fill all their needs, were feature poor, plagued with problems and expensive to implement and maintain.  Many of these problems were driven by the segmented nature of the industry and lack of critical mass to fund development and improve the solutions.  As a result, the same large firms are shown as satisfied users of multiple competing systems designed to meet the same need.

In the last 2-3 years, Oracle Corporation has started to expand the Oracle ERP applications into solutions that can better be utilized in the E&C space.  As is true with all the various companies that have offered products in the past, the Oracle Applications have significant gaps that need to still be met by other solutions or custom development.  One of the primary drivers behind the acceptance Oracle is finding in the E&C market is less how well it meets the specific needs of the industry and more the feature rich functionality it offers firms that have been struggling with limited user base and integration as business expands, companies merge and government regulation reaches deeper into the company.

Historically, consulting firms did not find much traction in the E&C industry. Solutions were fragmented and it was difficult to develop critical mass to support a consulting group.  As a result many solution companies either helped customers implement their software or clients were forced to self-implement using internal teams that were sent off to training.  With the sudden up turn in Oracle activity within the E&C industry, a new model has started to appear. Because Oracle has been widely used across manufacturing firms and has thousands of clients across international firms, a significant consultant base exists across the world.  Most of these consultants have strong Oracle application knowledge, understand the complexity of multinational business transactions and the utilization of Oracle applications within a business process re-engineering implementation.  Very few consultants have truly worked across both the ERP and E&C environments.  Since several parts of the solution still require niche or point solutions, this creates a significant challenge for firms doing a true global integrated solution.  This is further compounded by pent up demand that is being met by a software solution that is marketed heavily by the solution company to justify continued development work for the industry.  In contrast to the historic model of implementation, the Oracle solution requires consulting assistance to leverage the true benefits and cost savings envisioned in the ROI model that are used to justify the expenditure.  With limited experienced resources across the ERP and E&C worlds and multiple companies seeking to do their implementation immediately, there is very high demand for a limited number of specialized individuals.  This is driving a need to team across consulting companies to meet the implementation challenges found in the E&C industry.

In the EPC and E&C world, very few firms can offer the complete set of services required to accomplish everything from initial design through final punch list sign off.  What matters most is the ability to bring together the right resources, at the right time, in the right place, to keep a project on track, on schedule and on cost.  With the entry of Oracle Applications significantly into the E&C space, this same model applies.

Large project based organizations working in a multi-national, multi-currency environment struggle with how best to deal with currency issues when managing projects and reporting project and organization financial performance.

When dealing with currencies in a project environment, the following types of currencies come into play:

1. Functional Currency: The currency in which the financial books are maintained
2. Contract Currency: The currency in which the contract for the project is written
3. Project Currency: The Currency in which the project is managed. This may be different from the functional currency and very often may even be the contract currency.
4. Cost Currency: The currencies in which cost is incurred.
5. Revenue Currency: The currency in which revenue is accrued, this very often is the functional currency in which the project is setup.
6. Invoice Currency: The currency in which the project is to be invoiced.
7. Reporting Currency: This is the one currency in which all financial information across all projects is consolidated for management reporting.

Project based organizations run the gamut on the maturity scale in dealing with currencies. Some organizations are taking the first steps in expanding beyond current national boundaries and the issues involved keep them within their current currency boundary and they tend to execute solely in their primary currency only. On the other end of the scale are experienced multi-nationals that execute projects requiring serious hedging of currencies in order to maintain their margins.

Today we will address organizations from the lower end of the scale to those somewhere in the middle. In order to execute and manage effectively, the following currency setups are suggested for projects:

1. Project Currency = Functional Currency: This removes 1 level of complexity from the project manager’s plate and allows them to manage the project without the additional burden of currency management.
2. The Contract and Invoice Currencies should be as specified by the client. This is something that is typically negotiable with the client to determine who incurs the currency risk, the project organization or the project client.
3. The Budget Currency should be the project/functional currency and all budget v/s actual variances should also be managed in the project currency. This makes the budgeting process easier.
4. Costs may be accrued in any currency and revenue should be incurred in the functional currency to keep things nice and simple.

In light of this setup, let’s tackle reporting at two levels: single project reporting and organizational reporting.

Single Project Reporting
Reporting for a project is primarily for project management purposes and hence all financial reporting for the project manager should be provided in the project/functional currency. As budgets and forecasts are also defined in the project/functional currency, it makes all variance reporting easy.

Organization Reporting
Reporting for project organizations is typically accomplished in the following currencies:

1. Functional Currency: This works well for organizations (and rollups) that are within a currency boundary.

2. Global Reporting Currency: This is a currency in which financial information is consolidated across currency boundaries for management reporting. This currency is typically set to the currency in which the organization maintains it’s primary or management offices.

Setup and Maintenance of Global Reporting Currency
1. As mentioned above, the functional currency of the organizations main office location should be setup as the global reporting currency for ease of management reporting.

2. Exchange rates for converting projects from other currencies to the Global Reporting currency should ideally be setup with

a. Conversion rates to the global reporting conversion should be setup as fixed rates for any given year. This allows management and project managers to measure the performance of the project without including variances due to currency fluctuations.

b. Conversion rates will also be needed for future months/years in order to convert budget and forecast amounts for projects. These future amounts should be refreshed yearly based on the latest rates at the end of a given fiscal year. This may require budget/forecast amounts to be reconverted to use the new rates.

Any variations from the management reporting numbers so derived will differ from the financial numbers from the official books due to exchange rate variances.

Following this simplified approach allows any project organization to expand into international arena while protecting their project managers and leaving the currency issues to experts in the finance organization.

That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try and respond to your comments, etc in future entries.

Today’s topic deals with how time worked (by people/labor resources) is collected and accounted for on projects charged.

Organizations that manage by project, collect labor costs against projects via timecards. These organizations struggle with the rules/validations that need to be applied to this time collection process based on the following competing business requirements:

1. Need for accurate time reporting for
   1. Paying employees what they are due
   2. Collecting true cost of doing work in order to allow for accurate estimating for future work
2. Need for Time Costing for Revenue Accrual and Invoice Generation based on project contracting rules.

Labor Resource Classification
People who charge time to projects in any organization fall into 3 categories:

1. Exempt resources:  these are typically full time employees of the organization who get paid a fixed salary and do not receive any additional compensation for Overtime worked.

2. Hours resources: these can be full time or contract labor that get paid by the hour and are eligible for additional compensation (time and a half or double time) for overtime worked.

3. Contingent or Contract workers who work as employees on projects. From a time accounting perspective these employees fall into one of the above two categories and are not considered separately for the purpose of this discussion.

Time Accounting for Hourly Resources
Hourly resources need to enter all time worked with the appropriate classification (Regular/Overtime) in order to get paid and also to record accurate costs to the project, including additional cost incurred for overtime pay. The need to record all hours for the purposes of accurate payment to the resource also serves an additional purpose of providing accurate expended effort for the purpose of future estimation.This then leaves the question of what is billable to the client. This wholly depends on the nature of the contract. The contract may demand that they be billed for all time at a standard bill rate (thereby reducing the margin to the project for overtime worked and paid) or even that no overtime be billed at all; in which case the project will need to absorb the overtime hours and their related costs.

The piece of time accounting for hourly resources that I have not addressed here are the additional complications introduced with Government and Union Regulations like prevailing wages. This is another topic for another day all together.

Time Accounting for Exempt Resources
It is in the best interest of the project organization to enforce policies that dictate that exempt employees record all time worked to the projects on which the work was performed. This provides two major soft benefits, one of which was discussed above: that of collecting accurate data for improving estimating algorithms for future work. The other benefit that can often be obscured is the visibility provided to management for the people consistently going above and beyond for their projects.Now let’s see the impact of project contracts on accounting for time of exempt resources. Contracts for project work typically come in two flavors:

1. Time and Material: Billings against these types of contracts typically bill for each time item charged to the project. Billings are dependent on using schedules of bill rates for specific people or specific classes of people. Such contracts may further limit the number of hours that are billable on a per day or week basis and hence the billability of time charged will need to be adjusted accordingly.

2. Cost Reimbursement: These contracts typically include terms for billings based on cost multipliers, cost + fixed hourly/daily/weekly fee or even a fixed/variable fee over total project cost which is reimbursed (as incurred) upto a specified cap. The application of multipliers or fees on cost can get complex but is relatively simple compared to trying to figure out how to determine cost of time charged.

The issues arise due to the need to accurately determine the exact cost of time charged and this can get tricky in the case of exempt resources who work for a fixed salary irrespective of the number of hours worked. If exempt resource charge more time than the standard (8 hrs/day or 40 hrs/week) hours, then the daily/weekly cost rate for the resources needs to be spread over all hours worked in order to derive the true cost time worked. This issue is further compounded when the same resources work on multiple projects: in this case cost determination needs to look at all hours charged across projects.

This concept of spreading periodic cost rate for an exempt resource over all time charged by the resource is called effective costing. Some of the challenges in accomplishing effective costing include identifying all time charged by a person for a given period across all projects charged. Another issue deals with late time. If some time for a period is charged late, it may result in the need for recalculating cost for all time charged in order to accommodate the new time charges.

One solution that some organizations use to workaround the challenges of effective costing is to limit the entry of hours to the standard hours only, i.e. 8 hours a day or 40 hours a week. This solves the problem but is not a good solution for all the reasons discussed above.
Standard v/s Actual Costing of Time
One major challenge that needs to be overcome by any organization that wants to operate on a project basis is determining which of the following costing method they would like to use determine cost rates for people resources.
1. Standard Costing: In using this method an average cost rate is derived for all resources in a particular resource classification (Job Category) and then used for all resources in that classification
2. Actual Costing: The actual cost rates for each individual are used for costing time. A variation of this is referred to as Payroll costing, where in the costs from actual payroll runs are distributed over time charged to projects to determine project costs. Payroll Costing has distinct disadvantages in terms of timeliness of cost collection, especially as payroll runs happen infrequently and this can delay reporting costs on the project.

The following table lays out some of the advantages and disadvantages of these two approaches towards time costing.

These are some of the factors that can be used to decide on which approach to use and as is evident here, standard costing is preferred in most cases. The only time when users have no choice but to use actual costing is in very low margin industries like Engineering and construction where labor cost rates are known (due to prevailing and union rates) and the difference between standard and actual rates can actually wipe out the entire margin that a project may have planned for. Other times where actual costing may be mandated (almost) is when contracting with the government who typically provide you with Cost Reimbursement contracts and often audit your project costs to match your payroll. That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try and respond to your comments, etc in future entries.

Today’s topic deals with using Oracle Project Management (PJT) in a Project Manufacturing (PJM) environment.

PJM is a solution delivered by Oracle to enable ATO/ETO type firms that design and build manufactured items to client specifications. Each client order is managed as a project (due to hard time and budget constraints) but the execution is done primarily in Project Manufacturing.

PJT provides integrated automation solutions for use by a project manager (PM). There are some integration points and some issues that need to be highlighted in using these 2 solutions together.

Integration Points

1. Resource Classes

==> Materials: Can be setup to refer to inventory items from specified (in resource class screen) Item Master and Item Category set.

==> Equipment: Can be setup to refer to BOM resources (Labor and Equipment) setup in Manufacturing.

2. Deliverables

==> Deliverable Type of ‘Item’ allows for associating Items that can be setup as Inward or outward bound deliverables

==> For Purchased deliverables, you can setup deliverable actions for Purchasing which allows you to automatically create Purchase Reqs in PO for those items.

==> For Manufactured deliverables, you can setup deliverable actions for Shipping which collects additional information and then allows you to place a demand on the MRP and once the item is manufactured place a ship order on the item right from the deliverable action screen.

Issues
One major consideration in using the 2 solutions together is the level at which delivered items are planned for in PJT. The users can choose to plan at the (summary) delivered item level or at the (detailed) BOM components of the delivered items level. In either case there are issues to be considered in how this will be handled.

1) If planning at the summary level, the issue arises with collection of Manufacturing actuals and how these actuals are mapped to the planned summary items in the workplan for proper actual v/s planned reporting. The issue is as follows: When a delivered item is planned at a summary level, the actuals from Mfg come at the detailed BOM Component items level as these items are charged to the project as they are consumed in the build out of the summary item. Now when these actuals come to PA, they are stamped with the detailed Component Item and as this does not map to the planned item, it is mapped to the workplan as an unplanned actual: thereby doubling the cost.

==> The solution to this is to collect the final summary item on each mfg transaction as the detailed items are issued from inventory (in a DFF on the transaction). Then after these transactions are cost collected and pushed into the PA-Transaction-Interface table and before the transaction import process is run in PA, we need to change the item on the transactions from the detailed component to the summary item fro the DFF on the Transaction. Now when this transaction is pulled into PA and subsequently mapped to the Workplan it will show up correctly as actuals against the summary planned item

2) If planning at the detailed item level is desired, the issue comes of how to identify all the detailed components needed in the build out of the delivered item in order to plan for them on the workplan. In this case the Delivered items should be setup as a deliverable in order to place the Demand on the MRP as needed. Once this is done, there 2 choices

==> Manually figure out the detailed components and enter them as task assignments on the workplan

==> Have a custom – batch process, that reads the deliverable items and then fetches the detailed components from the BOM explosion of the item in BOM and automatically add them as task assignments to the task associated with the deliverable item.

That’s it for now and remember:

There is no better way to manage a business than to Manage by Project.

PS: I welcome all comments / trackbacks / pingbacks / queries to my nascent venture here. I will try

This is the first entry in what I hope will be a long running log of business cases, issues, solutions and anecdotes that I encounter in my day/s as someone who runs a project based business, implements ERP solutions for Project based businesses and advises users in project based environments. Here is a partial list of areas that I will cover in my entries:

1. Advantages and Issues in managing by Project
2. Project Management Processes
3. Project Management Discipline and determining where you stand.
4. What to look for in an automation solution for your project needs.
5. How Oracle Projects can help
6. Implementing Oracle Projects
7. Issues/Solutions in implementing/Running Oracle Projects
8. New Functionality in Oracle Projects FP.M and how it can help you
9. What’s new in Release 12 for Oracle Projects
10. Thoughts on Oracle Fusion Applications
11. Good practices in implementation services
12. Project Partner Products and Services that will make your life easier

Read the rest of this entry »