Which Makes Sense For Your Business – Managed Colocation Or Managed Servers?

Outsourced IT hosting services can range from raw colocation, which includes a place to house your server, the power to run it, and the connection to operate it online, to a fully managed dedicated server. A fully managed server typically includes all hardware and applicable technical services to keep your server up and running 24×7. The spectrum of services between raw colocation and managed servers allows IT managers to choose only the services that meet their company’s needs. They can pick from managed backup options, basic monitoring services, managed colocation or a completely managed server.

Managed colocation is similar to a fully managed server except that the hardware is owned exclusively by the client. With raw colocation, the server owner is responsible for monitoring and tracking, responding to and repairing problems with their server and taking preventative measures like backing up their data. With managed colocation and managed servers, many of those operations can be outsourced to a data center operator that can offer those services at a lower cost than a company could provide by themselves.

One advantage of managed colocation is that a client’s hosting needs and problems are being addressed by industry experts with extensive knowledge and experience. The client will not have to worry about hosting issues because they are paying for the managed services each month. With managed colocation the client will also be lowering their overall cost of IT management. Because the staff and space is being shared across many servers in the data center, the client will pay a lower cost than hiring data center staff internally.

Other than who owns the hardware, there are very few differences between managed colocation and a managed server from most hosting providers. However, one advantage of managed servers over managed colocation is faster remediation time on hardware failures. With a managed server, the hardware is owned by the hosting provider who most likely will have spare parts readily available to replace hardware quickly and the availability to substitute a similar server to prevent downtime during maintenance. For managed colocation, each client’s servers can differ dramatically and hardware failures often require time-consuming delays while coordinating the order, delivery, and replacement of custom server parts.

Managed servers possess similar advantages to managed colocation in that they can provide clients with expert management at lower costs than what it might cost to host internally. However, managed colocation is best for companies that already have the server hardware and expert IT staff that want to be in control of the management and just need the security and reliability of a data center provider and basic management services. The managed server option is better for companies that don’t have the staff or hardware and want more in-depth services than basic maintenance and problem solving. Both options allow a company to leverage the complete expertise of the data center staff and get absolute security, management, monitoring and reporting.

All things considered, with both managed colocation and managed servers companies should think of the services as a function of their business rather than just the outsourcing of IT services. Excellent data centers allow companies to pick and choose their desired services and level of control. In the spectrum from raw colocation to managed servers, every business can find an IT management solution that will work best for their scenario.

About Online Tech
Online Tech owns and manages SAS-70 secure and reliable multi-tenant data centers across the Midwest. With a full range of raw and managed colocation, fully managed dedicated servers, and server monitoring and management services, Online Tech reduces IT data center costs, operational risks and downtime and insures their clients’ servers are always on, always online, and always safe. Visit http://www.onlinetech.com for more information.

Posted in Uncategorized | Comments Off on Which Makes Sense For Your Business – Managed Colocation Or Managed Servers?

Project Management Objectives – PRINCE2 – 10 Areas To Think About

PRINCE2 is a widely used method in which objectives are a fundamental area of the plan for project management. They should be fixed and agreed ahead of time. Project progression is evaluated against the objectives.

Project milestones:

The moment these are attained, and objectives have been appropriately reviewed, authorization can be granted for the release of resource for the next phase of the plan. The following step, and any fresh objectives, will demand extra information and agreement.

Monitoring:

There are typically 2 elements to this. The first one is ensuring the project management objectives are met and the second one is just how you reached them, i.e., the actual process. Are there any lessons to be learned?

The Progress theme:

The Progress theme, in PRINCE2 checks the processes for keeping track of the actual progression from that intended. Additionally, it provides a projection of the project objectives with control of any alterations from what may be anticipated, that is, the variances that are not within allowed limits.

Authority and tolerance:

We appreciate that the PRINCE2 method uses management by exception. This is only achievable by using objectives with set tolerances. These have a definite impact on the amount of authority of individuals to operate. If a tolerance is established at’ 5 units’ and the outcome is’ 4 units’ the manager knows he may carry on with no recourse to a higher level of authority. Only when an objective boundary is surpassed will he need to consult a higher level. This is the point of tolerances, they enable somebody to decide to continue or not. Not surprisingly, this is the principal element for management by exception. Higher management only have to hear of exceptions that differ from the designated timetable.

The setting of the tolerances may be a complex procedure involving work to determine quality critical limits.

Any generation of project management objectives and their linked tolerances requires a formal systematic method. Otherwise, it is likely that various elements of the objectives will be neglected.

Timing of control methods:

Keep in mind, that any control methods should be put in place in a timely manner so that corrective steps may be taken. Therefore, milestones and objectives ought to be spread fairly uniformly throughout the project. Not too many, however enough, to acquire suitable control. Always review a schedule and test the number and frequency of objectives and milestones.

Risk management:

All projects ought to have a little management of risk put in place. It is pointless possessing milestones and objectives, regardless of how often, if you have a limited idea of the probability of specific events occurring that might upset the project plan.

The Gantt chart:

The workability of each project will only become apparent when the project schedule, with objectives, is established. The activity dates and additional facts will be less exact at the beginning of the project. For PRINCE2 2009 see the section ‘Plans – The PRINCE2 approach – Prepare the schedule’.

Unsatisfactory objectives:

In PRINCE2 any project ought to be realistic by virtue of the Business Case and fall in line with corporate strategies. If this is not the situation then a business might be managing different projects with out of step objectives. Indeed, these might be duplicated.

Delegation:

PRINCE2 establishes authority from one level to the next by delegating this downwards. This enables management by exception by specifying tolerances against 6 objectives at each level of the plan. That is, quality, scope, time (task duration), cost (budgets), risk and benefit.

Concluding the project:

This is the option to make sure that every objective referred to in the project plan has been satisfied. As soon as this happens the project has nothing remaining to accomplish.

Posted in Uncategorized | Comments Off on Project Management Objectives – PRINCE2 – 10 Areas To Think About

The Ten Commandments of Successful IT Project Management

Even with the best of intentions, managing projects in the Information Technology arena will always include elements of chaos. As a Project Manager you have a responsibility to effectively manage your project in a way that meets customer and stakeholder expectations.

Managing the expectations of your customers and stakeholders is just as important as understanding the vision and expectations of the initiative. Because you most likely do not have control over many of your resources, Stakeholders, Customers and Sponsor – identified process is the way in which you can successfully manage technical projects.

Identified process and communication of identified process will provide the parameters, expectations and the governance you need to be successful. In my experiences, failed projects all have had the same common thread; there was either a lack of defined process or identified processes were not properly communicated and adhered to. The good news is defined project management processes are available and made to be leveraged. The Project Management Institute (PMI) and Capability Maturity Model Integrated (CMMI) offer best of breed industry standard process in both Project and Organizational Management.

A project is defined as is a temporary endeavor with a defined beginning and end and often constrained by funding or deliverables. The following ten principles are essential and must be utilized for your project to succeed.

1) Sponsor / Business Commitment.

The Project Sponsor has the most interest in the project; in most cases the project is fulfilling business needs for the sponsor. Therefore, the Project Manager and Project Sponsor have a partnership and shared interest in the success of the project. In addition, the Project Sponsor usually controls resources and works directly with or supports the Project Stakeholders. Usually Project Sponsors are not understanding of the level of detail and commitment needed to successfully manage a technical project. The Project Sponsor must be engaged and fully understanding of the project scope and approach. In as much as the Project Sponsor needs to understand your commitment and approach, you need to understand the Project Sponsors commitment and expectations. Through the Project Sponsor, the business group must also have a clear understanding of their needed commitment and project approach. If the program does not understand and has not allocated time needed for their tasks, the project will most likely be delayed. A knowledgeable business team member will be required in many of the project phases including: analysis, JAD sessions, planning, design and testing.

2) Stakeholder Identification.

All stakeholders meaning all people affected by the project and or initiative must be identified. This is critical. Even successful projects can be a disaster if the initiatives are not understood at an enterprise level.

3) Project Scope.

It is critical that every project have a clearly defined scope that details all deliverables in relation to the business needs being met. The scope will be agreed on by the sponsor and all stakeholders, including Project Team Members. Any changes to the project scope will be addressed through the change management plan (discussed later).

4) Project Requirements.

Every project will need identified project requirements; the level of detail will depend on the complexity of the project. Generally, project requirements consist of functional (business) and technical requirements. The functional requirements address the business needs and may include: use cases, process flow diagrams, data needs, reporting needs, gap analysis, testing requirements and other documentation that accurately identifies the business needs. Technical requirements leverage the functional requirements with consideration to any technical standards and policies of the organization. Technical requirements may include: data base diagrams, architectural diagrams, screen shots, performance requirements and other technical specification and design documents needed to procure or develop the desired solution. It is understood that requirements are developed through analysis which will include Joint Application Design (JAD) sessions as well as interviews and or review of existing documentation. Both functional and technical requirements are to be reviewed, understood and approved by the designated project management Team.

5) Detailed Project Plan.

Contrary to popular belief a project plan is not just a Microsoft Project gantt chart/mpp file. A true project plan will consist of the following documents:

• Project scope – defined above

• Project requirements – Defined above

• Communications plan – A Communications Plan will identify all stakeholders who will receive communications, the level of communication, the method of communication and how often. This is important to set the expectation of how your stakeholders will be communicated with.

• Risk management – this document will qualify and quantify risks and how they will be mitigated.

• Gantt chart/project/cost schedule. This document; commonly referred to as the project plan will include time estimates, dependencies, milestones and identified resources. The gant chart includes the scheduling, dependencies and resources needed. This is the document that will be referred to when managing the schedule.

• Issues list/ action items. As issues are identified they will be included in the issues list, assessed and prioritized. The project team will determine how the issues will be addressed.

• Change Management Plan – The process in which scope change will be handled (described below)

6) Change Management Plan.

A change management plan identifies the processes involved when a requested change affects the project scope, requirements and or schedule. Typically the requested change, resolution, needed resources and project impact is identified by the project team. The final decision on how the request is handled is usually provided by the Project Sponsor and or Stakeholders.

7) Project Baseline

It is recommended the project be saved to a baseline. The baseline identifies the schedule and saves it. Any deviations from the base-lined schedule shall be identified and reported as part of status reporting.

8) Project Monitoring and Reporting.

Status reporting shall be done on an identified basis (determined in the communications plan) and include statuses regarding the schedule, cost, resources and any other issue which impact the project. In most cases an Issues list is employed to track identified issues and how the issues will be resolved in the form of a stated action.

9) Exception Management.

In as much as we would like things to go according to schedule, they rarely do. Exception management is a must and includes all actions relative to managing project exceptions. Exceptions include, project variances, schedule variances, scope change, resource issues, personnel issues, personality issues and any other issues you can think of.

10) Needed Skill Sets

To be most effective a Technical Project Manager should have a thorough understanding of: project management process, technical knowledge, and organization and communication skills.

Project Management is as dynamic and rewarding as it can be gut-wrenching; my advice- expect both. I hope this article provides assistance and a realistic reference for you to be most successful managing your projects.

Posted in Uncategorized | Comments Off on The Ten Commandments of Successful IT Project Management

PRINCE2: Principles: Manage By Exception

This is a term that people who are new to PRINCE2 will most likely not have heard before. As it is important that you understand it, I will start a simple explanation and then give you the PRINCE2 definition. When it comes to factors like time, cost, and scope, the Project Manager has some tolerance to play with before they have to advise the Project Board that there is or might be a problem (e.g. costs could change ±10%). If the problem is small and it remains within the tolerances (e.g. the costs increase by 2% — less than the 10% tolerance), then the Project Manager can deal with it and doesn’t have to alert the Project Board and take up their time.

Manage by Exception is used by each level in the Project Organization to manage the level below. The layer below should only notify the above management layer if there is a big issue that is outside their tolerance. The PRINCE2 name for a big issue is Exception, which means the issue is outside the agreed tolerance.

Now, imagine you are sitting on the Project Board. If everything is going OK, you won’t hear from the Project Manager except for the regular reports during a stage and at the end of the stage, unless there is an exception, hence the term Manage by Exception. The PRINCE2 definition for Manage by Exception is as follows: A PRINCE2 project has defined tolerances for each project objective to establish limits of delegated authority.

PRINCE2 lists 6 tolerances that can be set. These are Time, Cost, Quality, Scope, Risk and Benefit. I will give examples only for Quality, Scope, Risk and Benefit, as Time and Cost are easier to understand.

· Tolerance Quality: You are creating a new GSM (a common name used to refer to a mobile telephone in Europe) and you want the keyboard to work for an average user for 7 years but you have a tolerance of ±5%.

· Tolerance Scope: The requirements for a new GSM will have mandatory requirements plus ‘nice to have’ requirements. So the project can decide which ‘nice to have’ requirements to include, but must include the mandatory requirements.

· Tolerance Benefit: A Benefit is a measurable improvement resulting from the project for one or more of the stakeholders. These are benefits for the project stakeholders. For example, increase marketing share by 5%, or create a new profitable market segment. One question asked throughout the project is: “Is the project still on track to meet the expected benefits?”

· Tolerance Risk: Again, I’ll use the example of the GSM. There will be a set tolerance level for risk and if you hear of something that is above this level, then you will notify the Project Board. Example: You find out that the risk is now very high – that one of the providers cannot supply a 5 megapixel camera with the correct integration specifications. This can cause many issues for your project.

To summarize: Manage by Exception provides the above management layer with a system to manage and control the lower management layer, and they don’t need to be bothered by each small issue.

Posted in Uncategorized | Comments Off on PRINCE2: Principles: Manage By Exception

The Project Organization and Management By Exception

Getting the project team set up right relies upon you using Management By Exception

One of the key principles for project management success is ensuring that the PM responsibility must be matched by equivalent authority. The PM can’t be made responsible if they don’t have the ‘clout’ to make things happen.

Each individual on the project, and that includes the project manager, must be provided with a clear understanding of the Authority, Responsibility, and Accountability given to them so that their work can be accomplished. The Solution Lies In Design Of The Project Organization.

When designing the Project Team, start with standard roles such as User representative, hardware engineers, and so forth. Sit down and agree with the individual what responsibilities they will have, and what levels of authority for carrying out their work.

Make sure that these balance. Beware of giving someone (especially yourself!) lots of responsibility but not enough authority to carry out their responsibilities.

A useful one-on-one technique I have used in the past to generate quick agreement is to take a flip chart and draw a vertical line down the middle.

At the top of the left column write “This is what I expect of You” and on the right hand column “This is what You can expect of Me”

Do it in any way that feels comfortable (I usually like to do all the writing and let the other person freely give me their thoughts).

It’s a contract for working well together.

But here’s the thing.

You MUST also do it for management above you. As the Project Manager, you are responsible for delivering the project to times, coast and quality – but senior management have their responsibilities to the project as well. And these need to be agreed. Here are some examples:

Who ‘owns’ the Business Case – it’s not the Project Manager!

Who is responsible for agreeing the User Requirements and signing acceptance of the project deliverables – it’s not the Project Manager!

Who owns the resources – it’s not the Project Manager!

Who has the authority to approve Requests For Change or Off Specifications – it’s not the Project Manager!

Who approves all Plans and ‘underwrites’ the project – it’s not the Project Manager!

Also, beware of stakeholders who see themselves as ‘passive customers’. Be clear that if they are to be any part of the approval process within a project, they must become Active Participants. And that means getting involved early and contributing – and having responsibilities!

Each individual within the organization needs to have three key criteria agreed. So let me start by nailing down what these mean:

Authority. The power granted to a person so that they can make decisions that others are expected to follow. The position or role that a person holds is the usual way that authority is granted.

Responsibility. The obligation a person has to perform their assignments effectively.

Accountability. This means that the person is totally answerable for satisfactory completion of a given assignment.

These three attributes are vital if a project and business management is to complete successfully.

Starting at the beginning, it must be unfair if, after sign-off, the project manager is not allowed to respond to situations. In effect, their hands are tied – how can anyone manage in such as situation?

So the Project Plan is signed off, a budget is agreed, and an end date set. The first mistake senior management make is by stating things such as “I have now approved your plan and I expect you to deliver against it” So nothing can ever change – the project manager isn’t allowed to react to risks and changes.

And of course, the estimates contained within the Plan were perfect, customers never change their minds, problems never occur, the world never changes, and Santa Clause does exist!

But hold on; look on the other side of the coin.

Senior Management within the organization are responsible and accountable for some aspect of the business. They are investing in projects to help optimise what they are responsible for. If it was YOUR money – wouldn’t you want to tie the project down?

The Project Board should have representation from the customer/user side, and the supply side. The “Senior User” has responsibility for agreeing the requirements, acting as the main interface with the customer and users, and accepting the end-product from the project.

The “Senior Supplier” role is responsible for supplying all human and non-human resources to the project. Be aware there might be internal and external suppliers.

Note also that these are roles to be used or shared amongst one or more individuals.

Heading up the Project Board is the Executive who owns the Project Business Case, and has the final say in all project business matters.

Luckily there is a middle ground – a way that makes total sense providing organisations are mature enough to use it.

Just suppose that when a Plan was agreed, management gave the project manager some degree of flexibility (in the form of an agreed deviation from Plan), that management could tolerate. This agreed flexibility would be the PM’s playground that allowed them to do their job.

But what should happen if the PM suddenly forecasts that these deviations will be exceeded? Why of course, they must bring it to the attention of higher management and seek guidance.

But that last paragraph sounds like senior management have abdicated their responsibilities. What I mean is, once the Plan is signed off and the deviation is set – they can disappear off to the golf course until the PM tells them the project is completed.

No, not quite. Senior Management would want a regular report of ACTUAL performance against plan showing the allowed deviations. It allows them to question and advise the PM should they wish to do so. And they are safe in the knowledge that if, between these regular reports, the PM forecasts a significant deviation, it will be immediately brought to their attention.

Welcome to Management By Exception. Vital to organizational business management within the project AND central to Management By Exception.

That’s the principles – time to get specific.

Depending on your business you may use your own cultural names for the various roles that make up a project management team. Here are mine – feel free to change the role titles appropriate to your organisation.

The Project Board are appointed to provide authorization and direction, and the project manager (who reports into the Project Board), is responsible for day-to-day management of the project.

Now, on the project board are three roles, the Executive (owns the Business Case, and has the final say in terms of authority), the User Representative role and the Supplier Representative role.

Having approved the Project Plan, the Project Board need to set an acceptable deviation – this is called Tolerance.

Now, Tolerance can be time, cost, quality, scope, risk, benefit, in fact, any suitable metric. As a simple example, let’s assume Tolerance figures are given as plus/minus 10% deviation of the budget and project end date.

What this means is that the project manager can manage in the normal way with the AUTHORITY to take any appropriate management action AS LONG AS TOLERANCE IS NOT FORECAST TO BE EXCEEDED.

At the time of the Plan being approved, this Tolerance is set, along with the regularity of reports and their contents from the project manager.

Okay, let’s imagine we are part way through the project, and to our horror, we see that the project is forecasting to come in 15% over budget. This triggers the exception process, and the project manager must escalate the situation to the next higher level within the management organization – the Project Board.

Notice that we don’t wait until the deviation has actually happened, because it will be too late for pro-active actions to be taken. The Project Manager will inform the board by an Exception Report (this could be given verbally – but I would want it in writing!)

The Exception Report will contain the following information:

* A description of the cause of forecast deviation from Tolerance.

* The impact or consequences of the deviation

* Available Options to minimise the deviation or remove it completely

* The impact or effect of EACH option on the Business Case, Risks, and Tolerances

* A Recommendation with reasons, of the best option to take

This is sent to the project Board who need to make a decision on one of the options.

Note that one of the options could be to shut the project down prematurely.

The project board level of the organization, will now ask the project manager to draft a new Plan based on the chosen option and this is reviewed by them. A decision is made to approve the new plan (called an Exception Plan), or again prematurely close the project.

Once approved, new Tolerances are set and the project proceeds under the new plan.

Final Thoughts.

Unfortunately, upper management within the project organization, are often suspicious that the project manager may use Tolerance as ‘code’ for padding – and as a safety net for poor estimates and re-work.

But they have missed the point. It is there to give the PM enough authority to carry out his/her responsibilities.

So the tendency to start with, is the Project Board set VERY tight tolerances – with the consequence of the project manager forever raising Exception Reports to bring small deviations to their attention.

Experienced Project Boards (in particular the Executive), will know that Tolerance should be tied back and based on the Business Case. The Executive should ask themselves “what level of Tolerance can I TOLERATE before being bought into the loop and will this level of Tolerance deviation still keep the Business Case VIABLE”.

Remember also, that a Business case should be ‘viable’ (the cost and risks are worth the benefits?), ‘desirable’ (should we/must we do this?), and ‘achievable’ (can we do this?)

Posted in Uncategorized | Comments Off on The Project Organization and Management By Exception