IT projects are initiated when business identifies a need to change or improve their processes. Many process improvement or business transformation initiatives have an IT component. A company I worked with recently that was looking for an IT solution to help them drive improvements in their global procurement group. The key driver was a need to make operations more efficient to support aggressive business growth objectives. Essentially this was a business transformation project. The IT component in this case was a key part of the success of the project. The IT project would deliver more effective transaction system for procurement and better information for decision making.
Given the potential benefits to the business of these projects, it is not hard to get business support and sponsorship, as well as engagement of resources from the business side. However, expectations are normally high, and a clear understanding by the business of the rigor and methodology around IT projects is not always understood. The implementation of an enterprise IT system of this scale needs to follow a methodology that ensures that the rest of the systems are not impacted, and that good IT and project governance is followed.
So what happens when the requirements imposed by good IT governance slow down the delivery of the benefits of the business transformation project? Furthermore, how often do we see IT procedures and policies used in the name of good IT governance, that do not make sense from a business point of view? Does project methodology constrain business process improvement?
Good project governance around IT projects reduce risk. At the same time, they transfer some of 'ownership' of the solution from the business to IT; reduce the level of engagement of business; and extend project timelines and cost. Balancing business expectations with IT governance is a challenge.
Here are some of the key project aspects that we addressed to tackle this challenge on our project.
- Employed an iterative project approach. This ensures that small successes can be delivered to the business, and subsequent work can build on each project deliverable.
- Clear communications and business engagement. This manages expectations realistically, as well as ensures that project team stays close to business needs.
- Well defined and communicated project milestones supported by a well maintained project plan.
- Strong functional team leads who understand business processes and requirements; the technologies being deployed; and good IT governance, methodologies and tools.
Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts
Making the Business Impact Matrix the foundation of a Change Management Program
What is a Business Impact Matrix (BIM)? The BIM is the output of a thorough assessment of change impact on the business processes, people/organization and systems. Defining change means documenting the current situation and the future situation, then assessing the change that this means to each impacted group. Proposed actions for making this change successful means understanding the risks of not making the change. These actions need to occur to manage risk of change. The BIM assessment should also idntify the opportunities for the business of each change.
So the Key Elements of the BIM are:
Opportunities will support the Value Proposition that needs to be part of the communication around the change. The BIM will help guide the Value Proposition by impacted group, making communication to specific audiences more effective.
So the Key Elements of the BIM are:
- Defined Change.
- Identified Impacted Groups
- Risks of not Changing
- Actions to address Risks
- Opportunities of Change
Opportunities will support the Value Proposition that needs to be part of the communication around the change. The BIM will help guide the Value Proposition by impacted group, making communication to specific audiences more effective.
Applying LEAN to ERP System Implementations
"The speed of the boss is the speed of the team" - Lee Iacocca
LEAN methods have been applied to software development. LEAN methods, or Agile methods use development iterations during software develoment. These methods minimize risk by developing software in short pieces over short periods. These short development project pieces, or iterations allow for logical pieces of functionality to be developed; the bugs to be ironed out; and for project priorities to be re-evaluated.
How do we apply LEAN to ERP system implementations? Traditionally, a 'waterfall' approach is used on ERP projects. This means that you would design the solution first; and then configure the ERP software; and then test it. Using this traditional approach, project teams would have spent a lot of money and time before finding issues that may have required going back to changing the solution design, or system configuration.
But LEAN CAN be used to make ERP system implemenations more effective. This is how:
LEAN methods have been applied to software development. LEAN methods, or Agile methods use development iterations during software develoment. These methods minimize risk by developing software in short pieces over short periods. These short development project pieces, or iterations allow for logical pieces of functionality to be developed; the bugs to be ironed out; and for project priorities to be re-evaluated.
How do we apply LEAN to ERP system implementations? Traditionally, a 'waterfall' approach is used on ERP projects. This means that you would design the solution first; and then configure the ERP software; and then test it. Using this traditional approach, project teams would have spent a lot of money and time before finding issues that may have required going back to changing the solution design, or system configuration.
But LEAN CAN be used to make ERP system implemenations more effective. This is how:
- Spend time up front in getting requirements correct to avoid waste due to developing functionality that is not needed or defects.
- Break down Design concepts by critical business subprocesses or functional areas that can be tested and validated against business requirements.
- Plan iterative Design / Build / Test activities around these functional sub-system designs.
- Creating Learning Cycles around the Build and Test activities. This will reduce training effort and better utilize people's time.
- Align business processes around ERP system functionality – maximize asset usage; avoid having to customize the system more than you need.
- Avoid complex project plans. Use a milestone plan to drive achievement of project objectives. Use of Work Packages to breakdown work activities, if more detail is needed at that level. These Work Packages should be build around the iteration cycles that will lead to rapid deployment of the system.
- Rapid deployment – design, build, test and review pieces of the solution. This requires user involvement during design, testing and review – knowledge transfer reduces training effort of traditional methodologies.
- Document of design and review decisions – capture knowledge
- a quick, interactive process to achieve flow in the development process, and
- a knowledge capture process to improve quality, reuse, and repeatability of information developed in the interactive cycles
Building a Business Case for an Improvement Project
“Write your injuries in dust, your benefits in marble.” Benjamin Franklin.
How many times do we go into projects without defining the measure of success? That is what we do when we do not think through the cost and benefits of any investment in an improvement project. How can we measure how we haev achieved our improvement goals, if we do not have these quanitified in terms of the time and expense we put into building the improvements?
Building a business case does not have to be an exact science, and is simpler that many think. However, it does take effort, and requires buy-in from the project sponsor or the person who is signing the check.
Building the Business Case for a project is most commonly done using Excel. You want to estimate the costs & benefits over time with all of the assumptions that you will need to make, so that you can define the key project metrics that will help you decide whether to go on with the project or not. Below I have listed the elements of this business case: the costs and benefits over time, and the metrics.
Types of Costs
- One time costs to implement solution. Eg. project time & expense costs, hardware and software purcahses, etc.
- Recuring costs. Eg. depreciation, training, licensing, etc.
Types of Benefits. Below are examples of typicial quantifiable benefits of an business improvement project
- Increased number of customers
- Improved revenue per customer
- Improved customer retention
- Reduction in sales discounts
- Reduction in penalties, returns & credit notes
- Software portfolio consolidation
- IT maintenance cost reduction
- Reduction in capital costs
- Labor savings (by department)
- Improved cash collections
- Reduced stock holdings
- Faster training
- Other one-time benefits (
- Other monthly benefits
Business Case Metrics
- Payback. Payback period refers to the period of time required for the return on the project investment to "repay" the sum of the original investment. Calculating Payback Period using Excel
- Net Present Value: NPV measures the excesses of shortfalls of cash flows over time in terms of present value of the cash. Calculating NPV using Excel
- Internal Rate of Return: A project is a good investment if its IRR is greater than the rate of return that could be earned by alternative investments (investing in other projects, or even putting the money in the bank). IRR will be expressed as a percentage. Calculating IRR using Excel
Quicker System Implementations – Quicker Benefits
"If you want to get somewhere else, you must run at least twice as fast as that! " Project Management Proverbs.
Rapid Deployment and Lean Methodologies in application development are not new. These methodologies employ iterative cycles of designing, building and testing activities, to quickly validate requirements, and address development issues. In this way, defects and rework are reduced. This also gets requirements correct to avoid waste due to developing functionality that is not needed.
Even though these methodologies are not new, the execution of these methodologies in large ERP system implementations is not widespread as it should be. There could be several reasons for this. If you are a large consulting company with a big bench, it may not be in your interest to propose a shorter implementation with a smaller team!! However, I like to believe today the consulting industry is competitive enough so that businesses are smart enough to look around and get the best deal when implementing their systems.
I bigger hurdle to getting to rapid deployment with ERP projects is the planning for such a project. Rapid deployment/ lean approaches depend on breaking down the work into pieces that can be designed, built and tested in parallel. This requires a thorough understanding of business processes, business requirements, and of the ERP application – in planning the project! Project Preparation is therefore crucial in getting a rapid deployment project executed correctly. These pieces of the project can be defined as Work Packages or Learning Cycles. Some companies prefer calling these Learning Cycles, as that emphasizes the fact that the team needs to be continually learning through design, built and test to ensure the highest quality of the end product.
This approach requires early availability of system infrastructure for development and for testing / quality assurance.
This approach also requires early involvement of the user community in testing and QA activities. This supports early knowledge transfer, and thus reduces training efforts closer to go-live.
Even though these methodologies are not new, the execution of these methodologies in large ERP system implementations is not widespread as it should be. There could be several reasons for this. If you are a large consulting company with a big bench, it may not be in your interest to propose a shorter implementation with a smaller team!! However, I like to believe today the consulting industry is competitive enough so that businesses are smart enough to look around and get the best deal when implementing their systems.
I bigger hurdle to getting to rapid deployment with ERP projects is the planning for such a project. Rapid deployment/ lean approaches depend on breaking down the work into pieces that can be designed, built and tested in parallel. This requires a thorough understanding of business processes, business requirements, and of the ERP application – in planning the project! Project Preparation is therefore crucial in getting a rapid deployment project executed correctly. These pieces of the project can be defined as Work Packages or Learning Cycles. Some companies prefer calling these Learning Cycles, as that emphasizes the fact that the team needs to be continually learning through design, built and test to ensure the highest quality of the end product.
This approach requires early availability of system infrastructure for development and for testing / quality assurance.
This approach also requires early involvement of the user community in testing and QA activities. This supports early knowledge transfer, and thus reduces training efforts closer to go-live.
Key benefits of faster system implementations:
- Leveraging what is there! Building on what we know. Not re-inventing the wheel = innovation.
- Sharper requirements - stay focused on meeting business requirements. Less "fluff" in development.
- Reduced rework through quick design-to-test cycles.
- Learning cycles built into development - faster knowledge transfer.
- Controlled scope = simpler project plans and lower overhead. Milestone plans drive project performance.
Project Management for Dummies
PMI Definition: A project is a temporary endeavor undertaken to achieve a particular aim and to which project management can be applied, regardless of the project’s size, budget, or timeline.
Further, as defined in the 2000 edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide), project management is the application of knowledge, skills, tools, and techniques to a broad range of activities in order to meet the requirements of a particular project.
Essentially, project management is comprised of five processes:
Initiating,
Planning,
Executing,
Controlling,
and Closing
These five processes are wrapped around the triple contraints of project management. These 3 constraints will define a project, and any changes to any of these will impact the project enough to require review and approval by the project sponsor(s).
TIME
COST
SCOPE
The Project Management Insitute has also defined NINE knowledge areas
Project Integration,
Project Scope,
Project Time,
Project Cost,
Project Quality,
Project Human Resources,
Project Communications,
Project Risk Management
and Project Procurement.
Project management is used globally by multi-billion-dollar corporations, governments, and smaller organizations alike as a means of meeting their customers’ needs by both standardizing and reducing the basic tasks necessary to complete projects in the most effective and efficient manner. As a result, project management leadership is a highly desirable and sought-after skill as intense global competition demands that new projects and business development be completed on time and within budget.
PM a nutshell: 3 contraints; 5 processes; and 9 knowledge areas.
RELATED BLOG ITEM:- Project Management Resources
---------------------------------------------------------
Project Management Resources
Here are a few Project Management Resources on the web that I have found useful recently. I will add to this item as I find others. Feel free to send me links that you have found useful.
________________________________________
The Project Management Institute is the grandaddy of all PM sites. This is the 'duh' site for PMs where you get information on events, 'know-how' and certification - and so I have included it here.
_________________________
Association for Project Management is the UK-based PM association. They have a good site with links to great PM resources. They have recently released the 4th edition of the APM Body of Knwoledge to APM non-members.
_________________________
Ever looked a template for a project deliverable. Ganttheat has great resources for PMs, including good documents & templates to accelerate your project documentation.
_________________________
The Project Management Podcast
Cornelius Fichtner, PMP does a great job with this Blog. He seems to work hard to get the latest and greatest from the PM world, and so this Blog has useful links to PM resources and relevant news. I enjoy the Podcast as well.
_________________________
IT toolbox - Project Management Knowledge Base.
ITtoolbox is a great knowledge base for IT topics in general and specifically around IT Project Management. They also have a Wiki which helps to grow their knowledge base. Good stuff.
_________________________
TechLINKS is an online technology magazine focused on Georgia businesses (they also have a print edition). They have a Community Publishing area where you will find some interesting items on Project Management too.
_________________________
Mario Alexandrou is a IT PM based in New York who has a nice website. His Methodologies page is a good primer for IT methodologies.
_________________________
Managing Requirements
“Analysts report that as many as 71% of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure" - CIO magazine, Nov 15 2005
Managing requirements on software development projects has always been critical to the success of these types of projects. The tools and methods around these are well documented (try Google-ing “Requirement Management Tools”). However, Managing Requirements is rarely appears as an activity on system implementation projects.
System implementation methodologies will include the definition of requirements. For example, the SAP ASAP methodology (now incorporated in SAP Solution Manager) includes this during the Blueprinting Phase. However, this and most other implementation methodologies, assume that these requirements will not change. And in a perfect world, they will not, and you can design, develop, test and implement a business solution based on these stated requirements.
However, the world is not perfect!
People change their minds for many reasons, and do so on a regular basis. They'll be working with an existing system and realize that they missed a requirement. Or, during system build they'll realize that what they asked for really isn't what they want after all. If you try to "freeze" the requirements early in the lifecycle you pretty much guarantee that you won't build what people actually need, instead you'll build what they initially thought they wanted. That's not a great strategy for success.
Requirements management involves establishing and maintaining agreement between the business and the project team on both system and business related requirements. This agreement forms the basis for estimating, planning, performing, and tracking project activities throughout the project and for maintaining and enhancing the developed solution. Key activities include:
- planning the requirements phase
- establishing the requirements process
- controlling requirements changes
- minimizing the addition of new requirements (scope creep)
- tracking progress - tracing built-to requirements against original requirements
- resolving issues with customers and developers
- holding requirements reviews
Ensuring that requirements are managed in projects assures that the system that is implemented most closely supports business requirements; and thus has the greatest chance of success.
Subscribe to:
Posts (Atom)