Project Management Reading

Terms / concepts you should know: PM Triple Constraint of project scope, project cost and project time,
project selection methods, make buy versus buy decisions (the options and their pros/cons), requirements
determination, team and time management techniques

68% of IT Projects Fail

You read that right68% is a commonly accepted number when discussing IT project failures. Thats sure
a lot of projects. By why are there so many failures? There are many answers to that as IT projects are rarely
simple affairs but often it boils down to a lack of good project management on the part of the project team.
Project management is the process and activity of planning, organizing, motivating, and controlling resources
to achieve specific goals.
The consequences for failed projects are not insignificant. They include: damaged brand, lost goodwill,
dissolution of partnerships, lost investment opportunities and low employee morale. In this reading well
cover some components of good project management that will improve your odds of being successful.

The PM Triple Constraint

No discussion of IT project management is complete without an explanation of the Triple Constraint
the tradeoff and inter-related nature of project scope, project cost and project time. Well start by defining
these terms first. The Project Management Institute (PMI) defines project scope as: "The work that needs to
be accomplished to deliver a product, service, or result with the specified features and functions." A related
concept is product scope defined as "The features and functions that characterize a product, service, or
result." Henceforth any mention of scope will refer to project scope. When explaining scope to students I like
the analogy of a telescope. Say you wish to have a closer look at the moon. You focus your telescope and
zoom in as much as you until the moon fills your view. When you peer into the eye piece you see they moon
but little or nothing else. You dont see the sun, or Mars or Jupiter. In fact, if you close your other eye you
wont be able to see anything or anyone else thats in the room with you. Youll just see the moon. Like a
good telescope, tight project scope helps you to focus in on what you need to do and eliminates other
distractions or work that can lead you away from meeting the projects requirements. A well defined and
clearly communicated project scope is critical to project success.
Cost and time also part of the triple constraint and are much easier concepts to understand than
project scope. For companies and professionals, cost is simply the monetary expense of the project. Time is
can be measured in several ways but is often thought of in terms of man-hours i.e. the number of human
labor hours required to complete the project.
Now lets return to the triple constraint. The triple constraint recognizes the interplay between scope,
time and cost. If you want to maintain the same level of quality then a change in any one of these factors will
cause changes in the others. For example, say your boss whats the project completed yesterday but you
still have 400 hours of work time left to complete the original scope requirements. What can you do? One
option is to greatly reduce the scope of the project. If Mr. Boss will be happy with fewer features you can be
done with the project in less time and at a smaller cost. Alternatively, you can hire more programmers. This
will greatly increase the projects cost but may allow you to provide all of the requirements in less time by
increasing parallel production. But adding more workers to a project helps only up to a point. Why? There are
several reasons. First, there are often certain aspects of the project that must be finished before others can
start. Think about building a house. One of the first steps is to pour a foundation. Adding more workers may
help you pour it faster but it must still cure completely before you can put up the frame. Adding more

foundation crew wont change this. More framers wont help either. Some aspects of a project simply cant
be rushed no matter when the boss wants it done. Second, adding more workers to a project means greater
communication and management complexity. In our class, a larger student team means more schedule
conflicts, more confusion about who is supposed to do what and issues like Who has the most recent version
of the project? The result of too many cooks in the kitchen is well known and often referred to as
Diseconomies of Scale or Brooks Law which occurs when Adding more people to a project makes the
project later. Overall, as development teams become larger, the average contribution per worker
decreases. Thats okay, you may say thinking that the project size is somewhat fixed so there is less work to
go around with a bigger team But in reality, large teams encourage freeloading (loafing) and a lack of project
ownership among team members. Lastly, adding new team members once development has begun requires
time for the new arrivals to spin up on the project (figure out whats going on). Would you want a brand
new teammate for your course project half way through the semester? I suspect not.
The diagram below illustrates the relationship between time, cost and scope i.e. the triple constraint.

For students, the difference between cost and time are less
clear as the most valuable resource while in college is often
time. Further, completing this project will not cost you
money beyond what you have already spent to enroll in the
class so monetary cost isnt really a variable of consideration.
Now Im not saying money isnt valuable to you, Im simply
recognizing that for students, available hours are a critical
resource that must be carefully allocated to optimize success
in college. For students I explain the cost component of
their own triple constraint relationship as opportunity cost
the cost to you in terms of other things you might be doing
instead of working on the project to differentiate it from
the man-hours component of time. Opportunity cost is an
important concept and one that should be considered
frequently in my class.
Another important concept is that of scope creep. In professional settings, scope creep happens all
the time and is very hard to prevent. You show your client your progress and he cant help but be excited.
Great new ideas pop into his mind for amazing additions to the project and it is very hard to say no to and
excited client. But before long, the list of could you and wouldnt that be awesome additions is longer
than your arm and youve not got the time or money you need to make them happen. Remember the triple
constraint? If you increase the scope you will also need to increase the time and cost. The key here is to be
very clear about these increases. If the client is okay with an increased cost and delayed delivery and you are
capable of delivering the new features, then by all means, re-write your contract accordingly. But saying yes
to a lot of new goodies for your client without considering your additional time and cost will end very poorly.
The project will likely fail and/or the client will be disappointed both of which are very bad for business.
Much of your success with IT projects will depend upon your ability to manage your clients expectations.
Scope creep is also a big problem in my class. Many students get excited about the cool features they
can add to their projects features that go far beyond the stated project expectations (i.e. its scope) and
sometimes even beyond the maximum number of points I can award! I love the creativity I see in my
students projects and I see the learning opportunities additional features create. However, each feature only
adds a few points to the project grade and comes with its own opportunity cost time that could have been

spent doing something else. So should you add that additional feature or not? It depends. Your decision
should made with the goal of maximizing your return of investment (ROI). If you have an easy week ahead in
your other classes and you want to extend your programming knowledge then perhaps the answer is yes
add the feature. If midterms are fast approaching and youre struggling in your finance class then the answer
is probably no as you will likely enjoy a greater ROI for studying for your finance exam than you will from the
additional feature. Either way your decision should be a rational one focused on maximizing your ROI.

Picking Projects with the Greatest Likelihood of Success

While there are many things you can do that will improve your chances for success, some success will depend
on the projects you pick. There are three main ways for selecting projects.
Select based upon strategic alignment. Projects that align with the organizations main goals tend to have
higher success rates because greater buy-in, prioritization and managerial support. This support means less
work for you to secure the resources you need to complete the project. Projects that do not support the
organizations main goals can be viewed by many as a distraction to the organizations core mission and thus
are a much harder sell.
Perform a financial analysis. Much like your own decisions, organizational decisions are often made based on
ROI or on other financial measures (net present value, payback analysis, etc.). Projects with high ROIs are very
attractive to management after all, maximizing shareholder value is their fiduciary responsibility (at least in
publically traded firms). Calculating ROI with IT projects is very challenging however, as knowing the full costs
and ultimate benefits of a project before it is even begun is difficult. Sometimes, projects can be
benchmarked against prior projects or against similar projects at other firms but determining ROI for an IT
project is often as much an art as it is a science.
Categorizing projects. Another approach to selecting which IT projects to work on is by categorizing them.
For example, you may categorize a project as one that addresses an existing problem, one that creates new
opportunities for the firm, or one that supports managerial directives (new requirements). It is often easier to
obtain approval and support for projects that address current problems or directives because the organization
must respond to these categories to avoid financial losses. Projects that create new opportunities for the firm
can be important but a harder sell. If you are considering between different projects of this type youll
probably do best starting with those that align with the organizations strategic goals.

The Make Versus Buy Decision

Once you have selected your project you still have another important decision that will greatly
influence your likelihood of success left to make the make buy versus buy decision. There are actually four
options to consider: make it in-house, make it but outsource production, buy a commercial product off the
shelf solution and use it as is, buy a commercial product but then modify it to more closely fit what you need.
Now to be clear, in 110A youll be making your system no purchasing is allowed. In your practicum MIS
course and in your professional life however, making the system yourself is often not your best use of
resources. But how will you decide? Lets look at the different options.
Make the system in-house. With this option your company designs, codes, implements and supports the
product all by its lonesome. To do this your company needs many resources such as time, development
expertise, programmers, project managers, money, etc. Making the system in-house is often not the best
way to go since few companies develop such systems as a core competence. Would those resources be better
used on what the company does for a living? Also, making a product in-house means that the company

misses out on the wide scale testing conducted by other users of COTS (commercial off the shelf) products as
well as the standardized processes these product offer. Of all four options, making the system in-house is the
most time consuming and can be very costly as most proprietary systems do not create economies of scale as
do commercial solutions. All of these drawbacks may have you wondering why anyone other than the
software pros ever create a system in-house. The main advantage to making a system in-house is when doing
so allows the company to protect or support proprietary processes that contribute directly to the core
competencies of the company.
Make but outsource production. Here your company is involved in the design but coding is done by another
company. While that sounds easier than making in-house, managing relationships with other companies is a
major undertaking all in itself. And what the risk of giving your information, trade secrets and processes over
to someone else who may in turn sell them to your competitors? Further, who will maintain the system,
upgrade it, and support /train the end users you or your provider? One of the most common mistakes
companies make is to trying to outsource a problem. If you cannot find a solution yourself, how are you going
to explain what you need to a vendor? Vendors will give you lots of answers but even if you outsource
production youll need to understand your situation and constraints sufficiently to vet potential solutions and
select the one that best fits your companys needs.
Buying the system. Buying a system or solution as sold is another option you will need to consider.
Commercial off-the shelf (COTS) is a software package or solution that is purchased to support one or more
business functions and information systems. SCM (supply chain management), CRM (customer relationship
management), and ERP (enterprise resource planning) solutions are typically COTS or aggregations of different
COTS options from a variety of venders. There are many benefits to this approach. The market for software
is brutal and only the best solutions survive. By best I mean the most robust, bug-free and efficient
processes. When buying a solution that has already been vetted by others your company stands a better
chance of getting a robust product. Market driven quality and reliability are your friends! The market has also
driven out inefficient solutions and those products that remain are often best of breed approaches that,
when implemented, can save a company time and money. Additionally, COTS products are often designed to
integrate well with other products and platforms which may greatly simplify implementation. Also, these
products come with training, support and often offer insights into ways to improve the way your company
approaches certain processes that can lead to improved efficiency. Process improvements are a key driver
behind many companies adoption of COTS ERM solutions. COTS are usually your least expensive solution as
well as the cost of developing the project is shared by all purchasers rather than just one company. Buying a
solution off the shelf is a great option but of course one size does not fit all so implementing will likely mean
replacing some of the processes your organization currently employs with the processes dictated by the new
solution. This often leads to great efficiency but adopting someone elses approach isnt always easy and not
all your employees will happily embrace a new way of doing their jobs. Further, if you have a proprietary
process must keep and that you cannot change to work with a COTS solution then this approach is unlikely to
work.
Buy and then modify. Sometimes an almost good enough solution is out there so you buy a COTS product
and make changes to it so that it works better for your company. Your company can make these changes or
hire a company like Accenture to do them for you. This can result in a more fitted solution to your companys
current processes but in doing so you risk losing out on the process improvements of a standardized product.
Modify the software will also violate its warrantee and end user agreement so your company will also lose
product support (trouble-shooting, patches, user training, etc.) that came with the purchase.
Choosing the right option. Some questions organizations must consider the following when making a buy vs.
build decision:

1. Are there any currently available products that fit the companys needs? Is it a very common process
like an online shopping cart or payroll? If so, dont reinvent the wheel. Buy it COTS.
2. Are there features that are not available off the shelf and important enough to warrant the expense of
in-house development?
3. Can the organization customize or modify an existing COTS solution to fit its needs?
4. Do you need the system soon? Buying or buying then modifying is much faster than making.
5. Would making the product protect corporate core competencies? If so, youll probably need to make
it.
6. Do you have the resources to make it?
7. Is the solution very complex? Can you make it? Can you even describe the problem to someone else
so that they can make it?
8. Are you looking for process improvements?
9. If you make the system in-house, can you afford to maintain it, upgrade it, and support /train the end
users on your own?

Managing Yourself and Others for Project

Success
A big factor in the success of a project is in team and
people - this includes you is management. By their
junior year in college, most students have experienced
both highly effective and horribly ineffective teams.
At their best, teams create synergies that result in
outputs far beyond the sum of individual team
member efforts. At their worst, teams are, quite
frankly, a nightmare of poor communication,
indecision and time wasting. Creating an effective
team requires real effort on everyones part they
dont just happen and while it would be difficult for
one individual to ensure team success, there are some
things that you can do that will make a difference.
Create a shared understanding of what it means to
be part of the same team. One of the biggest
challenges teams seem to face in my class is
overcoming students different expectations of what
team membership means. For some students, team
membership means being in daily communication
virtually or face to face, discussing every option, etc.
For others it means clear delegation of tasks then coming together once a week to combine pieces and plan
the next deliverable. Students often have differing expectations regarding team communication frequency.
For example, one teammate might expect a response to an email within a few minutes while another
teammate thinks checking email and responding once a day is plenty. Personal goals also impact team
dynamics - some students want 100% on their course project while others simply want to pass the class. But
regardless of their source, teammates different expectations and assumptions can cause problems and

resentments to build up quickly. Discussing these issues and creating a shared understanding among
teammates about individual roles and responsibilities can help avoid many problems. To help you with this I
have created a list of questions and issues to discuss and address with your teammates in a document called
Team Ground Rules. You will submit your teams ground rules as a project deliverable.
Creating a shared understanding of what it means to be a teammate will also enable you to provide
each other with constructive feedback. I usually have one team each semester that struggles from the
beginning. Folks miss team meetings, deliverables are late or unsatisfactory. I receive frustrated emails from
different team members and tensions mount. I ask these teams over and over. Have you talked with each
other? Have you told teammate A that he needs to come to meetings or told teammate B how it hurts the
whole team when she doesnt deliver an assigned task on time? Often the answer is no or we told him not
to be late anymore but it hasnt changed his behavior. Delivering constructive criticism isnt easy. Receiving
it isnt easy either. Both take practice to do well. When giving constructive feedback try to first see the
situation from your teammates point of view. Do not just assume that a teammate is unwilling or incapable
of work. Look at the situation carefully and ask your teammate questions if necessary. Has your teammate
really just dropped the ball or has she working hard but is struggling with the code? If a deliverable is late, was
the task given too big for the time allowed? Has your teammate had some issues with family / work that are
interfering with his ability to attend team meetings? It is usually best if you start discussing team issues early
on in a calm and sincere way with the good of the whole team and of each individual teammate in mind. With
some thought and careful words, many issues can be dealt with before they escalate into unsolvable
problems.
If you are the one receiving constructive feedback try to understand that your teammates want the
group to succeed and see it from their point of view. That deliverable you couldnt finish on time could greatly
impact the project schedule and delay the start of other tasks. Stay calm and listen. If you feel the criticisms
are unjust then explain why. It is also your job to inform your team if you are struggling with your deliverable,
if you have been sick and unable to work or if you have something going on in your life that is preventing you
from putting in your best effort. I have had students in my office extremely frustrated with a teammate for
missing two meetings in a row, not attending class, not getting work done and not even answering emails. It
turned out that the teammate was very sick with the flu. If he had just sent his teammates a quick email or
text saying he was sick a whole lot of stress and frustration would have been avoided.
Honestly evaluate your contribution and that of others. Have you ever been on a team where you felt you
did all of the work? Or most of it? I have certainly felt that way only to later find out that my partner or
teammate really did work hard and contribute heartily to the project. Often we unintentionally over-estimate
our own efforts while underestimating the contributions of others. In a recent Harvard study, the sum of the
students self-reported individual contribution estimates were 139%. Why does this happen? Because you
are always on your mindyoure there struggling at 1am to get your code to workyouve been at it for
hoursit would sure be nice to have some help from your teammates! Meanwhile, a teammate may have
been working all day to complete his part and is thinking the same thing but you dont see his efforts or his
frustrations. Hes thinking hes carrying more than his fair share and so are you. Part of building a good
working relationship with your teammates is to help everyone (including yourself) to contribute meaningfully
and to recognize their efforts. One way to do this is to unpack the work. Dont just hand out tasks or take
them on without discussing as a team the amount of effort each task is expected to take. Create slack

spare time in your schedule in case you effort estimates arent accurate. Taking time to consider other
peoples efforts before your own helps to align your perception closer with reality and to create a more
harmonious team.
You can also battle our self-inflation biases with transparency. Make your accomplishments visible.
Instead of hiding away keeping mental score, keep a written record of the hours you spent, the challenges you
faced and how you overcame them. You need not track every minute but try to be realistic. It is easy to work
hard for 4 hours but in reality you checked Facebook for 30 minutes, had a sandwich, watched that funny
video your friend sent and answered 27 text messages from your boyfriend or girlfriend all within that 4 hours
so claiming all those hours as hard work is a stretch. When you and your teammates communicate your
efforts clearly and honestly youll better understand what everyone on the team is doing. This transparency
can also help with the constructive feedback discussed above. If a teammate works for 4 hours but cant get
the his or her part of the project working then perhaps the task was too large or complex and should be
revisited by the team. When you have a clear idea of what everyone is doing you can worry less about
contribution percentages and brownie points and focus on getting awesome things done together as a team.

Planning for Success

A big part of good project management is adequate planning. You may have heard the saying No one
plans to failthey fail to plan. Most folks understand the value of good planning and yet they shortchange
this stage anyway. Why? Because planning is time consuming and challenging if I cant do it well why
bother at all? For my students I think the drawback of planning is that it isnt nearly as much fun as coding.
Most would rather just jump right in and get started and unfortunately chaos often ensues.
Requirements Determination. One of the biggest challenges with IT projects, and many other types of
projects, is getting a clear understanding of exactly what needs to be done (i.e. accurately determining the
correct scope of a project). This process is often referred to as requirements determination and is critical to
the success of a project. Unfortunately good requirements determination is really challenging for several
reasons. First, it can be very difficult for a client to articulate all of his or her needs or worse yet have no
idea what they need to fix a problem they are having. Second, clients can also have unrealistic expectations of
what is possible with a given technology or budget. Third, technically oriented folks and those with little or no
technical knowledge frequently struggle to communicate because the two parties lack a shared vocabulary.
Here are some statics followed by a cartoon which illustrates the impact of poorly defined requirements.
1. Companies with poor business analysis capabilities will have 3x as many project failures as successes
2. Companies pay a premium of as much as 60% on time and budget when they use poor requirements
practices on their projects
3. Over 41% of the IT development budget for software, staff and external professional services will be
consumed by poor requirements specifications

As you can see, projects are often in trouble right from the very beginning. We will cover some methods of
good requirements determination in the reading on the Systems Development Life Cycle (SDLC).
Time management. Another important part of project management is good time management but doing it
well takes practice and dedication. For a lot of people, students especially, procrastination is a big problem
that undermines time management. We all have the one friend who is in a constant state of panic, always
racing to meet some deadline or another or maybe this is you. Sometimes a bit of deadline pressure can
improve your focus but racing the clock as a lifestyle has some serious drawbacks: 1) last minute work is
rarely your best work, 2) other folks (teammates, friends, family, etc.) often have to step in to help which can
lead to resentments and 3) its bad for your health. Studies show that extended periods of sustained
moderate stress are very harmful to the human body and can cause all sorts of diseases. With good time
management skills you can create a calmer existence. Im hardly a perfect time manager myself but here are
a few tips Ive learned that might help you too.
1. Break large tasks into smaller bits that can be accomplished in a short period of time. This can reduce
anxiety and also provide more frequent feelings of success and completion both of which are
motivating. I have done some of this for you with your course project.
2. Create a schedule. Once youve broken the project down into smaller pieces, try to determine how
long each piece will take to complete and then work backwards from the due date to determine a
reasonable starting point for each deliverable. Adding interim due dates and milestones (indicators of
the progress of work such as the completion of a form in your project) to your schedule can be very
helpful. Again, I have done some of this for you but feel free to add your own internal due dates to
keep your group on track. When scheduling recognize that 8 hours of work usually takes more than 1
day to complete because of needed breaks, losing focus after working on something hard for too long,
interruptions, etc. Allow enough time in the schedules for testing and revisions. I suggest you try to
finish each deliverable a day or two before it is due. This will leave time in your schedule to correct
glitches or accommodate the interruptions and distractions life often throws at us. Identify task
dependencies and opportunities for parallel work. Some tasks must be completed before others can
be started. For example, you will need to complete your course project database before you write
much of the code for your project. Other work can be completed in parallel. Could you be working on
the projects Login Form while a teammate writes the pseudocode for the Member Account form? You
bet.
3. Consider time blocking. Using a calendar set times for working on specific tasks. For example:
9-11 work on 110A project
1-3 study for my accounting exam
3-5:45 Class
You can also set aside the same time each day for studying. Time blocking may seem simple but many of
the most productive people I know swear by it for maximizing productivity.
4. Try load balancing: looking ahead at what is due across the next week (or semester) and spreading the
work out across the days. Load balancing is how I finished a lock-step MBA while pregnant (no

caffeine!) the first year and with a newborn baby the second year. While in my MBA I studied 6 days a
week every week for the whole semester even during the early weeks of classes when work was very
light. Most of my classmates took the first 3 weeks easy but then paid the price later in the semester
with all-nighter study sessions and lower grades than they desired. Would I have liked to take those
early days off? Of course. But when I looked ahead at my course schedules and saw the big projects
and papers and exams piled up from mid semester all the way to the end and I knew I would later
regret wasting those early days. Load balancing is also how I manage the feast and famine nature of my
academic career. Although it takes lots of discipline to be effective, load balancing is one of the most
powerful time management tools out there.
5. Align your mind and your work. We all have mental rhythms there are times during the day when
we are at our mental best and other times when are tired and unfocused. For early birds, mental high
times may be from 6 9 am. For night owls it may be from 11pm to 2am. Another time management
tool is to allocate your work so that your more cognitively demanding tasks are completed during your
mental high time. For me, 9am 1pm is when my mental cylinders are really firing. It is no
coincidence that I offer my classes at this time. I can and do teach at other times but I am at my best
from 9 to 1. This is also when I try to schedule my research time. I optimize my time by leaving less
mentally demanding tasks, such as grading or answering emails, for off-peak times. Aligning your work
with your mental rhythms can greatly improve your productivity.