Category Archives: Project Management

Outsourcing and Joint Ventures

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


Business application owners may dream of hosting everything in a heavenly cloud.  However, somebody somewhere must own the tangible infrastructure elements.  For large enough applications, there can be economies of scale or competitive advantages in owning your own infrastructure.  In some industries, privacy, security, or regulatory issues dictate that an organization host its own infrastructure.  If your organization or client is large enough, this may be part of your project.

Hosting your own infrastructure means making decisions about how that infrastructure will be managed.  Historically, organizations that owned their own infrastructure also maintained their own IT staff to manage and operate that infrastructure, with augmentation from specialized contractors when needed.  (Please see the accompanying article about procuring IT support services.)  In the modern era, organizations have additional options for managing IT operations and infrastructure.  In order of increasing complexity, these options can be summarized as:

  1. Managed Services
  2. Outsourcing
  3. Joint Ventures

Managed Services

In the Managed Services approach, the management of specific parts of the infrastructure are turned over to an outside organization.  The ownership of the infrastructure generally remains with the contracting or “owning” organization.  The Service Provider provides day-to-day “care and feeding” of the servers, storage, networks, databases, middleware, and other components of the infrastructure.  The management services are likely to be delivered remotely (frequently from India.)

From a procurement perspective, the Managed Services are generally contracted on a unit price basis.  The Service Provider generally charges these services for a specific price per server, per network port, per device, per unit of storage, per data center, and by other units of measurement.  The actual contracting is somewhat more complicated, as described further below.

Managed Services provide the IT organization with considerable flexibility in what parts of the infrastructure and operations the organization wants to continue to handle directly, and which parts should be contracted out.  The result may still be significant complexity in how IT is managed and measured.  With this approach, the owning organization still makes major decisions about how things will done, but “farms out” the work.  In the Managed Services approach, there can be an unwritten assumption that the contracting organization has superior (or adequate) skills and experience in effective IT management, but seeks to move routine work to another party that maintains a collection of superior technical skills and special tools (or adequate skills at an attractive price.)

Outsourcing

The Outsourcing approach moves more responsibility to the Services Provider.  There are a range of options, overlapping both the more simple Managed Services and the more complex Joint Ventures.  With this approach, the owning organization moves many decisions about how IT operations will be managed to the Services Provider.  The contracting organization will likely retain IT Executives above a certain level, but the Services Provider will be utilizing all of their own IT Management and technical staff.  The infrastructure may be housed in a data center owned by the Services Provider.  The infrastructure may actually be owned by the Services Provider.

From a procurement perspective, the Outsourcing Services are roughly and conceptually based on a unit price basis.  The Service Provider generally charges these services based on the size and complexity of the infrastructure.  However, there are likely to be additional contractual incentives for cost savings and risk management.

Outsourcing provides the business considerable isolation from the operational aspects of IT services and the decisions made in support the IT operations.  In the Outsourcing approach, there can be an unwritten assumption that the Services Provider brings superior IT management than the contracting organization chooses to sustain.

Joint Ventures

If the first organization has transferred enough business opportunity and risk, then it ceases to be merely the “owning” or contracting organization.  If the second organization is providing business services at a high enough level, then it ceases to be merely an IT Services Provider.  As the business value, complexity, and bilateral nature of this relationship increases, then the relationship becomes more of a partnership or joint venture.

The details of these kinds of joint ventures exceed the space here, and the contracting details far exceed the kind of procurement contemplated in the PMBOK.

Pricing

Both Managed Services and Outsourcing are typically procured using a kind of complex unit pricing.  The contracts are usually individually contracted using semi-custom pricing.  The pricing is usually structured as a rate per unit per month, invoiced monthly.  Customers may initially want a simple monthly unit rate price, but suppliers frequently use a more complex rate structure.  These structures may include rate adjusters called dead band, contract band, “arcs,” and “rooks.”

For example, if a reasonable market rate for supporting a specific device is $10 per month, and the customer has 500 such devices, the Services Provider may structure the contract price around a $5,000 monthly rate.

A dead band of plus or minus 2% would allow the customer to add or subtract 10 devices from their infrastructure without a change in the monthly rate.  An Additional Resource Charge (ARC) of $8 would add an additional (discounted) unit price for each additional device above the base rate, once the number of such added devices exceeded the +2% dead band.  A Reduced Resource Charge (RRC) of $6 would provide a customer credit for each removed or unused device below the base rate, once the number of such removed devices fell below the -2% dead band.

A contract band of plus or minus 20% would allow the customer to grow or shrink their infrastructure by up to 100 devices and continue to be supported and billed according to the base rate, ARC and RRC rates.  Once the customer’s infrastructure grew or shrunk by 20%, a contract re-negotiation would be triggered.

These contracts typically include different rates for different levels of service, such as how quickly different kinds of technical issues will be resolved.

For contracts of more than a year or two, the base rate is likely to include an annual rate reduction based on the assumption of future economies of scale, improved tools, etc.

These contracts frequently include incentives for component up time and penalties for component down time.  Pages of terms and conditions will describe how up and down times are measured.

Outsourcing contracts are likely to include additional elements, such as incentives for cost reductions, process improvements, etc.

Transition, Transformation, and Steady State

Both Managed Services and Outsourcing contracts will include pages of dense text with definitions of Service Level Agreements (SLAs.)  These represent commitments of technical and business responsibility that the Services Provider will stand behind.  For various reasons, the contracting organization and the Services Provider need a “get acquainted” period at the beginning of the service period.  During this initial period new monitoring tools are being installed and both party’s staffs are getting their processes integrated.  One name for this period before the SLAs are effective is Transition.  Once all the tools and processes are in place, a formal handshake takes place. At this point, the SLAs (and their incentives and penalties) become effective.  The services contract enters the main contractual period, which can be called Steady State.

There is an important distinction between the kind of work that is and is not included in a Managed Services or Outsourcing contract.  In a traditional self-governed IT organization, a typical staff specialist will spend various proportions of his or her time building, testing, researching, changing, monitoring, fixing, and tweaking things.  Within Steady State, these kinds of contracts generally only cover the monitoring, fixing, and tweaking activities.  An IT infrastructure is usually a continuously changing and evolving entity.  However, these kinds of contracts are generally focused on the things that are not currently changing and not expected to change much over the life of the contract.  For Services Providers, infrastructure undergoing changes is said to be in Transformation.   Service Providers are delighted to provide assistance with Transformation projects, but at a price additional to the Steady State supporting rate.


[I welcome your comments and feedback based on your experience managing or procuring IT services projects.  Feel free to contact me directly.]

(Image courtesy of stevepb at Pixabay.)

Advertisements

Procuring Facilities

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


Enterprises occasionally have a need to place some infrastructure in a different geography. An example would be a growing company needing to place infrastructure closer to a client set to sustain services performance in the face of rapidly expanding client demand.

With the great rise of public cloud service providers and hosting services, the need to arrange specific hardware in a specific location has somewhat diminished.  However, clients with interesting connection requirements or strict data proximity constraints will continue to drive the need for placing hardware in specific locations.

IT equipment requires a home that is hospitable, accessible, and secure.  Putting infrastructure in a specific geography requires some kind of hosting facility.  Acquiring or contracting facilities is often a project in its own right.  Analyzed through the procurement lens used in the PMBOK, facilities contracting would be considered unit-based.  The lease, utility, and operational contracts are based on square feet, power consumption, water consumption, air-conditioning load, etc.

There are a large number of businesses today that offer co-location services.  This service provides secured space in a shared data center with a tailored amount of supporting technical services.

When the organization has no physical presence in the target geography, and when cloud, hosting, and collocation providers don’t fit the requirements, procuring a small amount of facility space can lead to great creativity.  The organization may look first to see if it has any reliable clients, customers, partners, or suppliers with private data center space in that location.  Many IT organizations are experienced with hosting a secured corner of a data center for other parties as a revenue producing activity.  Some telecommunications firms will lease space close to their connection centers.  Finally, the organization may search for reliable but unrelated “neutral” firms with data center space.  The unit pricing model for these procurements may be straight forward.  However, the “devil is in the details” in the terms and conditions covering who will have what kind of access to the facility and the equipment under what circumstances.

Procuring a large amount of facility space becomes a real estate project with all the complexities associated.  Procuring a truly large amount of facility space becomes a real estate and construction project.  These are beyond the scope of my posting here today.


[I welcome your comments and feedback based on your experience managing IT real estate projects or procuring facilities.  Feel free to contact me directly.]

(Image courtesy of stevepb at Pixabay.)

 

Procuring Stuff as a Service

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


Powerful economic and technological forces have pushed IT resource consumption to the “as-a-Service” model, commonly referred to as “cloud.”  This is where Platform-as-a-Service (PaaS,) Infrastructure-as-a-Service (IaaS,) Storage-as-aService (STaaS,) Software-as-a-Service (SaaS,) and all the other  “aaS” acronyms arise.  These are essentially provided via unit pricing, in what is popularly called “pay by the drink.”  This afternoon, you can spin up an entire IT infrastructure using only a credit card and a good IT architect.  You will be charged incrementally for the number of sites, servers, network ports, storage increments, data units transferred, and/or transactions provided this month, this week, this day, and even this hour.

From the PMBOK perspective, this is the ultimate in unit pricing.  This can be challenging for the project manager procuring these kinds of services.  The unit prices are perfectly visible and reasonably predictable.  However, the actual project costs may be complicated to manage over a long enough horizon as the consumption of specific service units may be hard to accurately predict or to control.

When I spent some time working with a supplier of Stuff as a Service, we built complex custom spreadsheets to create the unit pricing model for specific customers (especially for the support services.)  As a consumer of these service, you may need to create a similarly sophisticated model to show the likely long-term costs for consuming these services in different operational scenarios or business outcome scenarios.

The services available in this cloud model cover a kind of “vertical spectrum.”  At the lower levels of the spectrum, where you are subscribing to infrastructure services, you are essentially renting hardware and renting the space in which it sits.  It should be easy to see that Infrastructure-as-a-Service still requires some kinds of infrastructure support.  (What happens when there is a product hiccup of some kind, and who will deal with that problem?)  At the higher levels of the spectrum, you are subscribing to capabilities where certain kinds of support are included and invisible.  Nevertheless, using these kinds of services frequently still requires some kind of ongoing support.  The higher the level of the subscription, the higher the level of auxiliary support required.  The subscribing organization may choose to provide that support itself.  This may be part of the organization’s core competency and competitive strength.  Alternatively, the organization may choose to subscribe to a supporting service to support the first service.

As an example, consider renting a car.  When the consumer rents a car, the automotive maintenance is included in the service.  The driver hopes to never see the specifics of how that service is delivered.  On the other hand, do Hertz and Avis each do their own vehicle maintenance using their own staff?  Do Hertz and Avis find that they have a competitive advantage in how they manage fleet maintenance?  Or do they contract vehicle maintenance service out to a supporting business?  (I am sure that all the rental companies study the finances of these questions almost continuously.)  I will cover how these kinds of IT support services are procured in a separate post.


[I welcome your comments and feedback based on your experience managing cloud transformation project or procuring these kinds of facilities.  Feel free to contact me directly.]

(Image courtesy stevepb at Pixabay.)

Procuring Consulting, Technical, and IT Support Services

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


IT initiatives and IT operations are notorious for requiring labor-intensive services provided by people with special skills.  IT project managers will need to be familiar with the various kinds of technical and support services, and how they are typically contracted.  In a nutshell, most such services are contracted using either firm fixed price contracts or time and materials.  Unit-based pricing for these kinds of services is generally limited to certain specific exceptions examples.

Traditionally, there has been some distinction between services offered remotely and services offered on-site at the client’s location or data center.  As the world moves to cloud, the distinction between on-site and off-site grows somewhat murkier.

I will outline some of the major IT service categories in increasing order of sophistication.

Software Support

One of the simplest IT services is software usage support.  A customer who has licensed a software package can pick up the phone or log into a chat service and talk directly with an expert in that software package.  This live contact “how to” service is usually tied in with live contact software defect support (described in an earlier blog post.)

This service is usually available on an hourly basis, but is more commonly contracted on a unit-based basis, with annual price based upon the number software licenses or the number of eligible callers.

There is a limit to the utility of remote software usage support.  This service can help the customer with “how to do?” questions, but cannot answer “what to do?” questions, and cannot directly perform the work needed.  This is a natural segue to the next levels of service.

Technical Support and Project Services

When a new IT infrastructure is being created, or is being transformed in some major way, it is common to bring in a team of technical specialists to build the new solution, raise a cloud of dust, and then get out of the way when the transformation is complete.  This is very typical for building new data centers and deploying new hosting environments.  It is typical for various kinds of migrations.  It is also typical for various kinds of optimizations, including urgent technical interventions.  Traditionally, this work has been done by assembling the team on-site in the client’s data center.  Nowadays, this may just as commonly be performed collectively but remotely for similar cloud deployments and transformations.

This kind of service IT technical service is usually performed on a project basis, and will likely require either a project manager embedded in the transformation team, though clients are advised to assign a corresponding project manager.  This work is usually contracted on either a fixed-price or time and materials basis.  The choice between the two mostly depends on which party is willing (or is required) to assume more of the risk in project completion.

If the project completion criteria can be sufficiently described, clients usually prefer to contract this work on a fixed-price basis.  If the project has too many known unknowns, or it the contractor believes that it is too important for the client to directly participate in the project, the contractor may decline to participate without a time and materials contract.

In some cases, these kinds of projects may be contracted on a unit-price basis.  An example could be a project migrating many servers or many storage objects from an old platform to a new platform.  If the migration rate or the final number of objects to be migrated is uncertain, the project might be contracted on a per-unit basis (probably with contractual bounds on minimal number of units.)  This provides for the case where the client might choose to wrap up a project early and wishes to simplify termination conditions and clauses.  This can also encourage contractors to maintain focus on client satisfaction.

Ongoing services that grow large enough to extend beyond a fixed duration project eventually segue into staffing services, managed services, or outsourcing.  Contracting for managed or outsourcing services are described in a separate post.

Staff Augmentation

The previously described IT technical services are generally project based, and are generally external to a client’s regular operations.  However, clients will frequently need to make a short-term to medium-term addition to their own staff for regular operations.  Contracting for a full-time but temporary technical specialist is called staff augmentation.  An important distinction about staff augmentation contracts is that the labor supplier agrees to provide a specialist with specific skills on-site, but the client must specify the work to be done and most provide its own project management of the specialist’s work.  An exception might arise when the client is hiring a large enough body of specialists that they choose to hire project management services as part of the augmentation.

Staff augmentation contracts can be comparatively simple.  These contracts include a short description of the skills to be provided and the time and materials rate to be billed.  If the technical specialist is to work at the client location, travel expenses are included in the contract.  These expenses are usually either billed separately from the hourly rate, or are included in the hourly rate.  Clients contracting for services to be delivered in a major metropolitan area may reasonably be resistant to paying travel expenses due to a feeling that sufficiently skilled staff should be available locally.  Some clients will have an organizational opinion that they should not pay travel expenses for philosophical or self-importance reasons.  In both these cases, the contractor will likely roll the estimated expenses into the hourly rate. The contracted price is described at an hourly rate, but invoiced on a daily, weekly, or monthly basis.


[I welcome your comments and feedback based on your experience managing or procuring IT services projects.  Feel free to contact me directly.]

(Image courtesy stevepb at Pixabay.)

 

Procuring IT Products

[This is part of a series of posts describing how IT contracting compares and contrasts with  the structure described in the PMBOK.]


The IT world continues moving quickly to cloud, but somebody somewhere must own the tangible infrastructure elements.  This may be your organization, your client, or part of your project.

Historically, you buy, lease, or license IT products, primarily with some kind of unit-based pricing.  

New and used hardware is offered for sale, and can usually be leased directly from the provider or indirectly via various leasing channels.  As with most technical assets, the purchase price (and thus the lease rate) for IT hardware is generally based upon capacity, performance, features, functions, number of units, and asset age.  Manufacturers offer a wide range of purchase price incentives, including volume discounts.

Bad things happen to good IT hardware, so most hardware maintenance is part of the ownership costs for infrastructure of any business value.   This is called hardware “break/fix” support.  New products usually carry a one-year or multi-year warranty.  Used products still in use after the warranty has expired are typically covered by hardware maintenance agreements purchased from the manufacturer or other support organizations.  

There are many books written and careers built upon the analysis of purchase versus lease decision for infrastructure owners.  IT project managers working in infrastructure organizations need to be aware of leases and their status.  In large IT-owing organizations, lease-ending periods can trigger hardware refresh projects that can impair or accelerate your IT transformation project.

Software is occasionally offered for sale, but is generally offered for license by software providers.  Software providers use a wide range of licensing plans, with the same software frequently being available under more than one licensing scheme.  Traditional software licensing charges are based upon the number of users (called “seats,”) number of transactions, or amount of underlying hardware “horsepower” (which can be measured several ways.)  Software licenses are similar to leases in that they are generally valid for a specific time duration and are generally charged on a certain time unit basis (typically monthly.)  Providers offer a wide range of licensing incentives, including volume discounts, and especially tie-ins with the licensing of other software packages.

Bad things happen to good software, so software “break/fix” support is considered part of infrastructure ownership in the same way as hardware support.  Software “break/fix” support includes the ability to receive certain kinds of software updates (“fixes,”) and usually commits the software provider to developing new software updates for bugs that the licensee discovers.  This kind of software support is generally considered different than software usage support.  The licensee is presumed to have sufficient staff expertise to be able to install, configure, operate, and maintain the software.  Major software providers offer software usage support, and may “bundle” software defect support with software usage support as one service offering.  In any case, usage support is clearly a service distinct from the tangible product.  I will describe contracting for that kind of service in a separate post.

Many IT hardware products contain a kind of embedded software that directly controls how the hardware functions.  This is referred to as “firmware” because its function occupies a logical space somewhere between tangible hardware and traditional software.  Legally, firmware is licensed.  However, the license is usually connected with the hardware warranty agreement and the hardware maintenance contract.

Technically, hardware and software maintenance can be considered services, but IT organizations frequently consider these to be part of the “costs of ownership.”  Contracting for maintenance is usually closely aligned with the procurement of the product itself.


[I welcome your comments and feedback based on your experience managing or procuring IT services projects.  Feel free to contact me directly.]

(Image courtesy of stevepb at Pixabay.)

IT Contracting in the Real World

Though procurement management is an important part of project management, candidates for the PMP exam are required to study and memorize a pretty curious contract framework.  Procurement and contracting in the IT world is changing in interesting ways, but is significantly different than what is described in the PMBOK.  The PMP requires the ability to describe three kinds of fixed price contracts and four kinds of “cost plus” contracts.  The PMBOK uses a range of acronyms for these seven types (FFP, FP-EPA, FPI, CPAF, etc.)  The PMBOK briefly mentions in passing two other types of contracts:  unit pricing and time and materials (T&M.)

The vast majority of real world IT contracts are firm fixed price, time and materials, or some kind of unit pricing.  In the jungle of IT contracting, the other contract types described in the PMBOK are rare, large, and perhaps dangerous animals.  Here is one framework for categorizing, comparing, and contrasting the various kinds of real IT contracts.

In a few following posts, I will provide some details on these kinds of contracts, and some considerations for the project manager whose project involves these kinds of procurement vehicles.

I welcome your comments and feedback based on your experience managing real-world IT contracting.  Feel free to contact me directly.


(Image courtesy of Poswiecie at Pixabay.)

Earning the PMP: Reading the PMBOK

Knowledge of the Project Management Body of Knowledge (PMBOK) is central to effectively serving as an effective project manager, and is core to passing the PMP exam.  One of the commonly heard pieces of conventional wisdom is that the PMP-candidate needs to read the PMBOK book cover-to-cover twice.  I followed another strategy that worked well for me, and might serve you.

In Summary

I only read the PMBOK once, but I systematically studied its contents and took organized notes with a focus on understanding the PMBOK and using it in my own projects.  I created a carefully structured set of notes that provided deep insight into the PM approach embodied in this body of knowledge and which made me comfortable taking the PMP exam.

A couple of my mentors suggested that I might be overdoing the preparation (“gold-plating” in PM jargon) as one only needs to complete the PMP exam with a minimum passing score.  However, I was truly seeking true working insight and was interested in strengthening my own mental framework for project management.

The Strategy

My strategy was to study in-depth the key content of the PMBOK and to take notes for my own understanding and to use in future projects.  In my projects since studying the PMBOK, I have found reviewing these notes to be useful for building new insights and approaches.

The Plan

As I carefully read the text, I created a set of notes in two main parts.  I created a document I call the 47 Booklet that has carefully organized notes about each of the 47 PMBOK processes.  To accompany the booklet, I created a set of tables that index, organize, and categorize the key elements in the PMBOK, namely the processes, plans, work products, tools, and techniques.

As I scrutinized each of the 47 processes, I took careful notes in my 47 Booklet on some key points:

  • Definition of the process
  • Benefits of using the process
  • The general approach to using the process
  • What are documented “good practices” for using the process?
  • What interesting details are shown or implied (or overlooked) in the process flow diagram?
  • What interesting details are shown, implied,  or overlooked in the described inputs, tools, technique, and outputs?
  • What are key project communications considerations involved in this process?
  • What are key considerations involved in this process in the opening days of a project?
  • What are key considerations for this process for a project manager brought late to the project?  (How do you catch up and gain control?)

The PMBOK has a large number of diagrams.  (Some readers might say it could use a few cartoons to liven it up!)  I built a list of the ones I felt were most important.

Some of my note-taking was just to assist memorization or to organize my thoughts, but some of it was to discover important insights buried in the dry text and to stimulate some of my own insights.

I scrutinized the introductory chapters and the chapters associated with the PM process groups.  I barely scanned the PMBOK Annex and most of the Appendices as these are “meta” materials included primarily to provide structure for the main content.  I did read the appendix on interpersonal skills.  I had considered systematically studying the glossary, but ended up merely skimming it.  Studying the glossary in depth might be important for non-English speakers taking the PMP in the English language.

After completing my note-taking process, I went back and reviewed a few key parts.

  • Important figures and tables
  • Early phase ITTO/A
  • Compared and contrasted the “Plan” processes, especially including the difference between the flow diagrams.
  • Compared and contrasted the “Control” processes, especially including the difference between the flow diagrams.
  • Reviewed the processes with unique action verbs.  (The ones with “Identify,” “Acquire,” etc. instead of the usual “Plan,” “Manage,” “Control,” etc.)
  • Reviewed the processes associated with getting a project started.
  • Reviewed the processes associated with wrapping up a project at completion.

The Schedule

I created a study schedule for myself for:

  • Studying the introductory chapters
  • Studying the 10 chapter introductions for the process group chapters
  • Studying each of the 47 named processes.

Early in my PMP-preparation days, when I was only studying part-time, I put on my calendar a day each for the introductory chapters and for each of the 47 named processes.  (Thus, about 50 calendar days planned.)  Later, when I was studying full-time, I shifted to studying a block of 3-4 processes per day, corresponding to an entire PMBOK chapter or PM process group.  I spent about one hour on each named process.

For your interest, here is a part of my study schedule.  The tasks in the Cheat Sheet 1 column are from my plan to memorize the order and relationships between the PMBOK’s 47 processes.  If interested, you can read more about my successful memorization method here.  The tasks in the 47 Booklet column are my schedule for studying and note-taking on the 47 processes.  The tasks in the PMBOK column are my schedule for studying the book’s first few introductory chapters and the overview sections of each of the main chapters.  Rita Mulcahy produced some very effective learning materials, and the tasks in the Rita column are part of my schedule for using her books and audio CDs.  I also included in my schedule (but off screen in the diagram below) some tests, quizzes, and exercises from some courses on Udemy by Joseph Phillips.  Joseph offers an Udemy course called Master the PMBOK Guide 5th Edition that could be considered a coached, guided tour of the PMBOK.  You might find that less painful than my approach.

capture

Acknowledgments

I want to thanks my friends and colleagues who suggested that I study for and take the PMP, and who encouraged me along the way.  I especially want to thank my loving wife and family for their patience and encouragement, especially while I was camped out at the kitchen table for a few days.


(Image courtesy of Poswiecie at Pixabay.)