COMP8110 first lecture

We have taken first class of COMP8110 (Managing Software
Projects in a System Context). This class will equip me with tools and practices
to manage a project. In the first class, I have seen a general overview of
Project Management phases.

One question raised in the class is "Why more than one
critical path would worry the project manager?" I would like to list some of my
answers:

There may be variables that you have limited control
over them. These variables are creating more than one solution to your problems
and each of them is critical path.
You need to assess the risks continually till you reduce
the critical paths to one. This is an ongoing process and will be re-visited
once you have more constant data for the variables in item 1.
Uncertainty arising from the critical paths which will
destruct the trust amongst PM and project members.
These critical paths will disturb the project plan and
budget. This is enough to worry the PM.
PM will not know if he/she has the enough resources and
skills to resolve the critical paths and issues escalated from them. Because
they are unclear.
Even customer may not be aware of the critical paths and
solutions. So PM can’t get a definite answer about the Critical Paths.

While I was seeking Dr. Boughton’s permission to reference
to him in this entry he corrected me about my answers to multiple critical
paths. He said:

"The main thing that the PM will immediately become aware
of is the fact that multiple CPs usually mean one or more of the following:

Inadequate resources
Short schedule with a hard deadline
Serious slippage with the consequence that too much work
has to be achieved in the time left."

After this discussion we explored the phases of project
management. These are:

Planning
Execution
Closure

These phases are divided into items below.

1- Planning

Initiation
Define Charter and Scope
Prepare a Work Breakdown Structure
Identify who is responsible for what
Estimate size, effort, resource and cost
Prepare a schedule
Resource allocation
Quality Plan (Review, Inspection, Testing)
Risk Management Plan
Change Control and Configuration Management
Communications

One of my suggestions was to include the Security under a
topic or add it as a separate topic here. You need to establish some sort of
security guideline both for the Intellectual Property protection and Security
for the product (like encrypted communication channels, user & group rights,
secure code writing etc.).

Implementing a security layer in code could increase your
task timing and exceed the scheduled time. Therefore Code Security should be
included under Work Breakdown Structure and budgeted accordingly. A "security
testing" phase could be added into Quality Plan to test the product whether it
is complying with certain security requirements.

Securing Intellectual Property is a broader subject that
needs to include organisation’s procedures to recruit people and the sensitivity
of the project (that is if the project is handling sensitive data). In this case
you may seek a certain level of security clearance from the project
stakeholders. Getting a security clearance for a member of the team can be time
consuming and may result in extended delivery times which will -again- disturb
PM’s project plan.

2- Execution

Monitoring, measuring and reporting the
progress
Controlling the progress
Change control and revision
Human Resource management
Communication management
Software Quality management
Resource management

3- Closure

Auditing (physical, functional, trust)
Post-Mortem
Terminating

There are also human factors that are affecting the
Project Management. These are:

a- Characteristics of Project Manager

b- Ethics (Company, personal, social)

c- Conflicts and negotiation

d- Meetings

One good discussion was about an opportunity of a software
project with some certain criteria. So you have been asked if you take over the
project with these criteria:

Immutable deadline
Under budgeted
Functionality is not easily reduced
Serious political & reputational consequences if fails
Must deliver an operational product of high integrity
Project can be cancelled at any time by customer.

So did you take over a project like this? What can you do
to take it? Here are some answers of mine and the people in the class:

Decline the offer
Manage expectations and be upfront with customer
Find a Commercial Of The Shelf (GY and another guy)
Setup positive relationship with the customer
Send the project to overseas (outsource) (GY)
Get the best team you can find
Find another customer with similar requirements and
share the cost (GY)
Identify best platform and tools that will provide best
results
Search Open Source libraries for bits and pieces that
you can reuse for this project (GY)
Negotiate ownership and keep Intellectual Property (GY)
Assume future investment
Force reduction in functionality
Discuss reduction in quality
Develop a good understanding of requirements
Establish a clear agreement of scope
Confirm customer’s expectations with real deadline,
quality and budget
Evaluate cost & risks
Do a feasibility study
Identify what are the criteria for cancellation

This project was a real story from Dr. Boughton’s past and
they (Dr. Boughton’s company) took it!! I have asked him "how did he convince
himself to take it"; He said they have done the items 2, 4, 6, 14, 15 and
recruited some of the key people who worked in this particular area before. They
also kept thinking positive about the project.

Share this:

Like this: