POINT OF VIEW
Project management is 90% administration, 10% inspiration, 100% stakeholder management, and 1000% frustration. What you don’t want to learn will make you stronger, and may help you focus on what matters.
Project management is about achieving a defined outcome in a defined time with defined resources. A bit like a Rubix cube – you have to follow the rules, unlike a Rubix cube, the rules change – all the time.
A project management course gives technique and some insight into how to deliver a successful project. The reality confirms the techniques are limited and actually it’s about people, politics, and focus.
Delivery of integration and connectivity projects is quite different from delivering applications. Integration projects have more stakeholders, the technology is fixed and varied, the impact of change is broader, and the potential for disruption to the business is greater. Testing is more difficult to imagine – let alone perform, and the changes are almost certainly going to impact important production systems.
Responsiv Consulting do this all the time – and we are here to help!
1: A Project Solves a Problem – so what is the problem?
A project manager is responsible for marshalling the resources needed to solve a problem, which is generally to successfully deliver a change to a systems landscape, achieve a contract signing, or to achieve some other defined context and “measurable” outcome.
The first problem is to properly define what success means in a defined context (scope).
The second problem is to understand the power and resources available to the project.
Having clear success criteria allows us to measure progress and understand when we are finished. They must be unambiguous and objective with no reliance on opinion.
- “fix the problem”. What problem, how will we demonstrate fixed?
- “Solve the Rabbit overpopulation”. How will this be measured, for how long, and what are the rules? We assume we have to avoid introducing diseases or new predators?
Some sponsors do not have a full idea of the requirements or what they exactly want. The result is that the project must do the work to define the requirements and then the project. This is not something that can be avoided. Poorly defined goals will become a major challenge as the project progresses.
2: Learn to Handle Several Projects at the Same Time
Organisations of all sizes have multiple projects running in parallel to deliver a mixture of customer work and internal initiatives. The demand for resources and number of projects will vary by size of organisation, creating the same resource constraints regardless of situation.
The project manager must prioritize projects and assign resources to minimise impact to project deadlines and costs. The important questions to ask are:
- Can the milestones be rearranged to smooth demand for resources?
- Which projects can be delayed while minimising delivery impact?
- Can we train or acquire more capacity with the right skills?
- What can be done to prepare and optimise use of the key resource and minimise the time they spend on a project?
The new UK IR35 regulation will reduce liquidity in the skills market by undermining confidence and attractiveness of the freelancer market. As a project manager it is useful to have a black book of contacts that can support your search for skills.
3: Change Request May Arise Any Time
At any point during the project the sponsor may raise a change request, which is a request to change certain aspects within the project.
A common example is when a new requirement is added to the existing scope. Changes may be minor or major and will affect the project accordingly.
For every change request the project manager will spend time reworking the plan and allocating new resources to the project. This can be time consuming and harder when resources are working on different projects.
4: Use Documentation to Avoid Circular Arguments
Project managers must document everything about the project, especially decisions, issues, and events that allow us to track progress and project performance. When working on multiple projects it is important to ensure separation of information (even if it must be duplicated in different projects). By having completed these in this manner confusion will be avoided and focus maintained on the project.
5: Design before Implementation
Developers have a tendency to start working on coding before the solution is properly defined or evaluated. The excuse is the time required to write documents.
However, the nature of the project can change at any time meaning that the resource who was working on a project might be asked to join another project or the project might be suspended for some time.
If the resource leaves and someone else need to pick this up without having adequate data recorded it can become challenging for the new person. If the project is suspended for some time, while resuming the project the resources will not have anything to refresh their memory, unless design documentation is provided.
6: Find solutions not people to blame
Problems are common in projects, especially working in a team of more than two people. When issues arises and individual feels threatened, there can be a natural distinct to defend ourselves, this might lead the team members to play the blame game. When problems arise it is important to focus attention on the problem and not whom to blame. Shifting the blame to others won’t help us to solve the situation, the project manager will have to establish a clear and distinct definition for the roles, responsibilities and accountability of the individuals.
Managing resources you don’t have authority for can become challenging; for example, customers, contractors or staff who work for customers or outsourced staff. The main challenge with these stakeholders arises when a document needs to be reviewed and signed off. As you don’t have the authority over these resources it can be hard to obtain sign offs and to manage their work time.
8: Ensure that meetings stick to subject and time frame
Project meetings are essential to maintain the momentum of the project. However, there can be situations where the meeting doesn’t finish on time and as a result, all of the subsequent activities or meetings have to be postponed. To prevent this from happening a few things can be implemented.
- Create agenda for meetings and follow that. This will advise all the attendees what topics must be covered during the meeting.
- Any topic that will require more discussion time must be included at the beginning of the meeting.
9: Learn to handle unexpected delays
The sponsor can take a lot of time to sign off the documents. Often only a policy or contractual change can handle this problem.
Requirement specification, design documents, deliverables, artefacts, testing documents are some of the mandatory documents that must be signed off by the sponsors during the project life cycle. It has been noted that certain customers can take a longer time to respond to the sign off request.
This can affect the project in many ways, and it may even pause the project impacting on the resource allocation and critical path.
To mitigate this problem, ask the customer to sign off the document over email with a deadline date. If the deadline is missed chase up and find the reason why. Establish if any additional support can be provided to the customer e.g. walkthrough of the document.
10: Delivering bad news
It is not an easy job to deliver the bad news to the sponsor or informing your upper management team that the targets have not been met. Bad news is not always avoidable during project life cycles, primary reasons for this could be because of the lack of project resources. It can be hard to disclose bad news to the stakeholders, however it is not good practice to withhold such detail.
Conclusion and next steps
This view is focused on some of the challenges of managing projects successfully.
We know that companies have a great deal going on, our project delivery services can be tactical or strategic, and can move from being tactical to strategic. Either way the initial implementation needs to deliver value and demonstrate the opportunity, otherwise what’s the point?
If you decide to give it a go, then we will start with a discovery phase. This involves reviewing the processes that may be candidates for automation, and identifying two or three that can be delivered quickly and that will demonstrate value.
We have no doubt that our consultants can bring significant efficiencies to your organisation and look forward to our first conversations.
Products and services relevant to this point of view include Responsiv Consulting, Responsiv Unity, Enterprise Integration, Enterprise Automation, Robotic Process Automation (RPA), IBM Cloud Pak for Integration, IBM Integration, IBM Automation, IBM DataPower, IBM Application Connect Enterprise (ACE), WebSphere, IBM MQ, IBM API Connect, IBM Business Process Manager, IBM Digital Business Automation (DBA), IBM Business Automation Workflow (BAW), IBM Operational Decision Manager (ODM).
*By pressing submit you agree to receiving communication from Responsiv. You may unsubscribe from communications at any time.
Ivanin is a Technical Consultant at Responsiv. He specialises in System Integration with IBM Integration Bus, IBM ACE, and IBM MQ, and is skilled in systems analysis, design and integration, API development, web development, and database design and development.
Ivanin’s other interests include cybernetics, cloud technology, containerisation & orchestration and the DevOps culture. He continuously strives to expands his knowledge and keep up with the strides of modern technology.