Gurkan Yeniceri

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:

1. 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.
2. 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.
3. Uncertainty arising from the critical paths which will destruct the trust amongst PM and project members.
4. These critical paths will disturb the project plan and budget. This is enough to worry the PM.
5. 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.
6. 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:

1. Inadequate resources
2. Short schedule with a hard deadline
3. 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:

1. Planning
2. Execution
3. 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:

1. Immutable deadline
2. Under budgeted
3. Functionality is not easily reduced
4. Serious political & reputational consequences if fails
5. Must deliver an operational product of high integrity
6. 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:

1. Decline the offer
2. Manage expectations and be upfront with customer
3. Find a Commercial Of The Shelf (GY and another guy)
4. Setup positive relationship with the customer
5. Send the project to overseas (outsource) (GY)
6. Get the best team you can find
7. Find another customer with similar requirements and share the cost (GY)
8. Identify best platform and tools that will provide best results
9. Search Open Source libraries for bits and pieces that you can reuse for this project (GY)
10. Negotiate ownership and keep Intellectual Property (GY)
11. Assume future investment
12. Force reduction in functionality
13. Discuss reduction in quality
14. Develop a good understanding of requirements
15. Establish a clear agreement of scope
16. Confirm customer's expectations with real deadline, quality and budget
17. Evaluate cost & risks
18. Do a feasibility study
19. 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.

Suggested readings

There are 2 IEEE standards recommended in the class these are:

IEEE 1058 SPMP

IEEE 1490 PMBOK  

I have also found a 1996 version of PMBOK which was another suggested reading, as a pdf file by searching in Google. It is a 182 pages document explaining the phases which I have mentioned above.

So up to next week, stay in tune...