Friday, December 26, 2008

MANAGING OUTSOURCED PROJECTS

As a small or medium sized business owner wanting to expand your business you have a dilemma, do you get the extra work and then employ extra people to handle the work, or do you employ the people first? Either way will put your business under pressure, you either don’t have enough people to do the work, or you have too many people and, potentially, no work for them to do.

Avoid Risk

It’s painfully obvious that growth is important to all businesses in order for them to be deemed successful. However employing other people can be very difficult, complex and expensive option. You may like to consider using outsourcing as a method of growing your business.

Outsourcing basically means that you choose certain activities that your business currently handles and then delegates these to external firms, usually for a predetermined fee.

However, there are some tips to bear in mind when you are choosing a company or individual to whom you are considering giving your business:

First, you should be sure that your outsourcing partner will not try to engage directly with your clients. As this company will be often dealing directly with your hard-won customers, you have to trust them. A contract should be drawn up to ensure that this company does not attempt this.

You also need to make sure that the person you are hiring has the appropriate skill set which is required to complete the work to the necessary standard and in good time. Your customers won’t want to hear excuses about how your failure was actually someone else’s fault and are just likely to walk away and not use your company again.

Once you have chosen your outsource firm you should then make sure you ser up a robust Service Level Agreement with them (SLA). The Service Level Agreement should explain what you expect from the service that they provide, including the time frames when completing the project.

When you are hiring an outsourcing company it is also acutely important that you have a thorough process that is designed to monitor the outsourcing of the product. You need to know any and all of the details about your chosen outsourcing company, the time line that you need them to work to, and any special requirements or information that pertains to the project that you will need to pass on to ensure that the eventual product is to your, and subsequently, your client’s, entire satisfaction.

You also need to add other things to this list, but each project will be unique and you should consider your information flow very carefully before engaging an outsourcing company.

Offshore Outsourcing

One popular type of outsourcing is to outsource products abroad to developing countries like China, India and the Philippines. These types of outsourcing projects are designed to reduce direct costs and overheads and, in turn, increase profits. For example, in the UK, US and Australia, many customer consumer support lines have been moved to India to reduce these aforementioned overheads, and much manufacturing of staple, and indeed specialist, goods have been moved to China.

In Conclusion

Outsourcing projects to other firms could be a great way to reduce your businesses overheads while still getting the work done. It’s also a very good way of growing your business without exposing your business to unnecessary financial risk. Owners of small businesses often have to multitask and juggle a number of projects which are all on the go at the same time but, by outsourcing, it is possible to reduce the workload without substantially increasing overheads.

Picaso Consulting can support you in this process either by managing your offshore partner or in helping you select that partner.


Tuesday, September 16, 2008

Managing Risk in a Project

Even if you plan your project down to the last letter, there are still a number of bumps and holes along the road, each of which could be enough to derail your project and make it become a failure. There are a number of different types of risk that your project may be susceptible to, we’ll take a look at these now.

Inherent Risk
This is also known as Business risk, and is the type of risk that could affect the business as a whole. Depending on your type and structure of organisation this risk will be different. For example a highly fragmented business has a greater risk of poor communication being a damaging factor in a project’s potential for success.

Specific Risk
This is also known as Project risk, and is the risk associated specifically with your project. Again, this type of risk in unavoidable and every project will be subject to an element of Specific Risk. Nevertheless, many of these risks can be influenced and mitigated against by the prudent actions of the project manager, such as the selection of collective skills of the employees chosen to work on the project.

Stage Risk
This is the risk associated with the particular task in hand during a certain phase of the project plan. For example, in a large urban building project, there may be risk in one phase that you have problems with logistics whereby delivery trucks need to arrive on time and in sequence in order to facilitate the overall workflow.

Planning for risks
To keep on top of all these potential risks it’s a very good idea to have a formal plan of all the potential risks you could encounter. This is commonly referred to as a Risk Register. Risks may be difficult to spot, and so you should ask for the input of everyone involved with this particular project. In fact, it is often members of the project team at lower levels of the organisation that may be able to identify smaller, yet still significant potential issues as they are likely to have a greater working knowledge of the potential end product than the managers or other senior employees. A series of formal, and informal, workshops might be a good way to get other peoples opinions.

Assess the Risks
Once you have identified the panoply of potential risks, you must then assess each of the risks to try and work out how likely it is to happen and what the impact of the realisation of the risk is likely to be.
The easiest way to do this is simply give your risks a score of 1-10 depending on how severe and how likely it is to happen. These scores can help you to spot the important risks that you need to keep an eye on. However, the traffic light system is another commonly used risk identifier, which has the benefit of providing a good project risk overview at a glance.

Risk Prevention and Mitigation
Risk is almost impossible to prevent, but it can me minimised and mitigated against. As such, you must continually assess the importance of specific risks, as during different phases of the project the likelihood of each risk could change.
For every identified risk, you need to come up with a suitable and cost effective counter measure. If, on consideration, it’s possible to completely remove a specific risk by subtly altering the workflow, then this can form a sort of pre-emptive counter action. If it can’t be removed completely then effort should be taken to minimise the subsequent effects of the risk as much as possible.

Issues
We’ve just spent some time looking at risks, a risk is something that could happen but hasn’t happened yet. An issue however is something that has already happened and is potentially causing a problem. Putting things right in a project when it HAS ALREADY gone wrong is a complex subject and outside the scope of this article, but if it has happened to you, there are many articles, books and journals that will be able to help you in this regard.

How to manage Risks and Issues
In conclusion, it’s important to monitor and keep an eye on the effectiveness of risk avoidance measures to find out whether or not they are successful. With careful project management, it should be possible to minimise, even if you can’t eliminate, the impact of virtually any type of risk in a project.

The types of risks that would be in play for an outsourced project would include but not be limited to those mentioned above.

We at Picaso Consulting can support you in managing the risk of your project. 

Sunday, June 15, 2008

Defining a Workplan in a Project

People that are not familiar with project management often think that it’s a very simple job that anyone could do. If you’ve ever actually tried to manage a project then you will know that this certainly isn’t the case! Many people who are not used to managing projects end up overcomplicating things, which can cause other problems.
If you want to take a project management role on, then it would be a very good idea to understand exactly what the role entails. Picaso Consulting aims to suport companies throughout the project management life cycle.

Assembling your Team
Before you can get on to designing the workplan for your project you need to assemble your team. This should include a representative from people who will play a part in the project. Be sure to include customers, employees and subcontractors. This is an important step as it helps you to define the roles of each person.

Objectives
This is the step that most people skip, you need to think of exactly what you want to achieve by doing the project. Although you may know already, it’s important to think about it again now.

Plan
You should then organize the project into a simple work plan and make sure that you include the estimated durations in the plan. The idea of the plan is to work out how the project will be completed. The project manager should be able to use the plan to predict when certain phases of the project will be completed; it will be used to stay on target to finish on time.

Enhance your Plan
Once you have your initial project plan you should improve it by adding more information to it. You need to consider the costs, risks and resources. For example every company has a limited number of employees, these are resources. If the project manager believes that employees are too busy, then some form of contingency planning needs to be worked into the project plan.


The cost of the project is also important, if you run well over your estimated amount then the value of the project plan will be greatly reduced. Moreover, accurate cost forecasts will help you to manage your cash flow much better.

Sometimes something occurs to endanger the project even if you are doing everything you possibly can. In this case, you should use risk management techniques to minimize the risks.

Trial and Error
Once the team has published your project work plan, many people think that you can just sit back and relax. That’s just not the case!
You should keep an eye on the project and continually adjust the plan if you need to. These adjustments to the plan should be used to minimize the risks, make up for delays, or incorporate scope changes. The plan can be republished and given to stakeholders until no more correction is needed.

Closure
Once the project has been completed the project can be closed by the project manager. This will include filing away the project documents, and some financial tasks. As a project manager, you should be willing to learn from your mistakes, in order to benefit future projects.

Allow Picaso Consulting to help you deliver the projects in a timely and Professional manner.

Friday, May 16, 2008

Change Reqest Management

Given that a project is a dynamic process, it is unrealistic to assume that requests for change will not occur. These changes will originate from changes in the user requirements and/or difficulties in realising the user specification in practice. Project Management via the Project Management Office need to manage the process and at Picaso Consulting we support in ensuring that this process is run effectively and efficiently.

One of the most effective methods of dealing with the need to amend projects is to have a project change procedure. Although this procedure will not remoe all risks, it will enable some changes to be made with minimal disruption and slippage. These request for change will occur in all implementations and it is vital that the process is well managed.

The Change Request Management plan is a definition of the formal process for making changes to the project’s original scope. It generally involves redefining existing objective and deliverables or specifying new project objectives and deliverables. The procedure for changes is as follows:

Change requests should initially be awarded a change priority classification code based on a set of standards. These can be either simply alphanumerical, or descriptive such as Critical, High Importance, and Medium Importance etcetera.

After the change request evaluation, the project manager should schedule a change decision meeting. Participants in this meeting should include the project sponsors, the change review committee, the project manger, the originator of the request, as well as any other interested and affected stakeholders.

The project manager will present the proposed change and the results of the evaluation, including a copy of the proposed project plan illustrating the impact of the change. The requestor may choose to speak on behalf of the change and the evaluators may also choose to defend their evaluation, if necessary. The project manager should only become significantly involve if the evaluation indicates that the proposed change would have a significant effect on the overall project in terms of finance, scheduling, or the eventual effect on the project’s service or product.

In all but very minor cases, the later that a project change is made, the more difficult it will be to implement without significant repercussions. The ramifications of the change will also vary proportionally with the size of the change. It may be that minor adjustments here and there may have a negligible effect, but a significant change in scope may set a long project back several weeks, months, or even years.

In short, a change request management procedure for any given project should include, but not necessarily be limited to the following:

- Identifying the need for change.
- Change recommendation.
- Analysis of the feasibility of change.
- Steering committee approval.
- Project sponsor approval.
- Amendment an agreement on the revised project plan.
- Implementing the change.
- Continue constant review.

The final task is to communicate the revised change request plan to all project team members and stakeholders, explaining the rationale where resistance is encountered. It is also important at this point to ensure that the minutes of meetings, decisions reached and agreements made are documented and retained.

In conclusion, change should be expected in any given project, but, as discussed in this article, is very much a manageable issue of the simple steps discussed above are followed.

Picaso Consulting consults in Strategy and Technology. We optimise your Business through Business Consulting and IT.

System Implementations

Sound planning of the implementation is crucial to its success as poor planning and inadequate resourcing are often primary causes of System Implementation failures.

The scope of most implementation can be huge. Not only does it include installation of the new software and the hardware it is to run on, but also precipitates panoply of potentially difficult and unavoidable human factors. Appreciating the conflicts that may arise will enable the organisation’s management to predict likely trouble spots and mitigate accordingly and in good time. Picaso Consulting can help you predict the likely troublespots and help you in unlocking the value within your organisation.

The key skill is for the company’s management to understand that the new system by itself is not some sort of silver bullet. The entire implementation process involves the complete business process and/or pedagogic practice, customer service, interaction with suppliers and a bond with all other interested stakeholders. Many less tangible activities are crucial and those involved must:

Have a sound understanding of the organisation, particularly in terms of its culture and values. The rationale behind any new system implementation should have thoroughly considered how the system is likely to help provide a better service to all concerned with it;

Undertake a very comprehensive review of all business processes and, where necessary, pedagogic practice, and begin to develop and introduce new policies and procedures before tuning the system to meet the agreed requirements;

Have a complete appreciation of the complexity and flexibility of the system;

Have an understanding of the inherent dangers of customisation of any software and how these can be mitigated against;

Conduct a thorough set systems testing procedures, whilst accepting the potential need for software 'bug fixes' and upgrades;

Budget for the real costs of internal staff time and their training and development;

Train all users to use the system and to fault-find and correct autonomously;

Acknowledge the critical nature of system documentation;

Careful planning and efficient management of the implementation are vital to success and to negate the threats of spiralling costs, extended timescales, losing key personnel and general dissatisfaction with the outcome.

Finally, it is crucial that the “go live” day causes as little disruption to the day-to-day business as is reasonably practicable. Issues that only arise at this juncture become magnified and will undeniably adversely affect the organisation's reputation, sometimes irrevocably, with all stakeholders. It is important to remember that poor project management and lack of communication at this crucial stage can ruin an otherwise faultless implementation.

Monday, May 12, 2008

The Importance of Project Management

Picaso Consulting 's Alfonzo Venturi comments that one of the key purposes of Project Management is to predict as many negative potential outcomes in a business venture as can be reasonably foreseen; and to implant effective mitigation strategies into the system such that the project is completed as successfully as practicable in the face of the identified risks.

The omnipresent nature of uncertainty in every business model means that events and tasks leading to a project’s completion can never simply be unfolded with unequivocal predictive accuracy. Moreover, for some innovative, groundbreaking and complex projects, even the possibility of successful conclusion is by no means a certainty.

The discipline of Project Management has developed in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects and thus remove as much of the controllable risk from the business system. In industries such as pharmaceuticals, software, aerospace, and defence projects drive a much larger proportion of the business and, as such, the discipline’s importance is absolutely paramount.

Project Management’s importance has it roots grounded in the way in which it secures the venture’s desired outcomes, usually in the form of SMART objectives. These can be set under generic headings such as:

Performance and Quality.
Project Management will ensure that the end result equates to purpose for which it was intended. Previously, quality was seen solely as the responsibility of a quality control department, but, with the advent of Project Management concept of Total Quality Management has come increasingly into vogue, which has shifted the responsibility of quality upwards to the Strategic Apex, as well as the Operating Core.

Budget.
Across all industries, margins are steadily decreasing and the need to bring in projects on, or under, budget is becoming a sine qua non in every business undertaking. Financial sources are never an inexhaustible resource and projects often end up abandoned when the allocated funds are used before the project is completed. Poor project management in this area precipitates significant waste in money and effort, as well as bringing some severe criticism of the project’s SRO. In some extreme cases, the project contractor could find their public standing reputation ruined beyond repair.

Time to Completion.
With ever shortening business cycles and the rapid pace at which business takes place, successful project management is important to ensure that all delays are identified early and mitigating action put in place to ensure that the project is brought back on track. All significant stages of the project must often be complete the specified dates as failure to do so can delay milestone payments or incur significant financial penalties. Additionally, late completion of projects can also damage the contractor’s overall reputation and may make repeat business harder to come by in the future.

Conclusion
Project management has become on of the most important skills that any company or contractor should have as an integral part of their overall service. It can be argued that effective project management is equally as important as the technical ability or level of service provision as allowing the failures highlighted in this article to materialise can have significant negative consequences for the SRO and contractor, and, indeed, the economy as a whole.

Picaso Consulting can support you in achieving your objectives.

System Software Testing

For all bespoke systems, whether written in house, or externally, or, indeed, any off the shelf packages that have been adapted, testing is an integral part of the system’s development process and we follow this at Picaso Consulting

Testing normally roughly follows the structure of the well known V-Model, although some testing systems do recognise a simpler, four stage testing procedure as outlined in this article. Testing, therefore, can be broken down into four elementary stages:

Testing the logic of the system
The technique of dry running can be used to make sure that the logic that has been set down by the analyst is correct. The programmer or analyst will trace, often by hand, the progress of a number of sets of data through the system’s schematic diagram or flow charts. If all data follows produce the results that are expected, the individual programmes can then be written.

Programme Testing
Each program is then thoroughly tested with test data, which is carefully selected to make sure that all of the sections of the programme are working properly. This part of the testing process should be documented very carefully with the data being tested, expected results, actual results and any discrepancies being recorded and sent for further investigation.

The programme testing documentation created at this stage is of vital importance for overall system knowledge and is critical for subsequent system maintenance.

System Testing
Once it has been established that the individual programmes are working correctly, the system should be tested as a whole. This is an equally important task, and the results should be documented in the same way as those for testing programmes. It is not only the software that is being tested during the system testing process, it is also important to test operating procedures and the human-computer interface, for example.

System testing can be carried out prior to installation or immediately after implementation. The maxim holds that the more pre-installation testing that is carried out, the lower the risk of failure following installation. However, this offline testing cannot always find all of the problems within a system as some will only appear during the live phase of testing.

Acceptance Testing
The final phase of testing needs to be carried out by the eventual users of the system and this will be the first opportunity to do this as the previous testing procedures should have been completed by the system programmers and analysts. It is probably of greater importance to ensure that the eventual users of a system will accept it as whether or not it actually meets the initial specification. Users will normally operate the system with dummy data and their use of the system will be monitored very closely. On completion of this process, the users will report their objective and subjective findings in order that final refinements can be made, where necessary.

The involvement of the end users does not however, have to wait until this point as their early involvement will undeniably assist in identifying potential difficulties earlier in the design process.

Conclusion

The four stages of software testing here also correspond to the well known software development lifecycle where each phase of software writing is matched by a corresponding phase of testing, which, in turn links to the V-Model as used throughout industry today.