Most project managers will answer the question by saying that they only have one project sponsor. This is a great answer – and it is far easier to manage a project with only one sponsor.
But for some projects, we find ourselves managing two (or, infrequently, more) executives who all want the role of sponsor. For example, a project where you are launching new software for the customer service division may have the IT Director as a sponsor (as her team provides the deliverables and manages the work) and the Customer Service Director (as his team is the one which will be using the output when the project is finished).
So who is in charge? Read more »
We’ve all heard it a thousand times before, we all know it well: a company is only as good as the people that work for it. Just because it’s trite doesn’t mean that it’s not true. Far from it, it’s one of the truest cliches out there. Things don’t happen on their own, they happen because people do them. Companies and successes don’t build themselves, their built by the people that work for them. Success happens when motivated people put in the hard yards.
But How Do You Motivate Your Staff?
This is one of those eternally difficult questions with no definite answer, every organisation and every staff member is different. The best thing you can do as a manager or business owner is to make your staff feel valued, rewarded, and best of all, to make them feel like a team that does things together rather than a group of individuals.
You could try telling them to value each other and work well together, or you could try team building exercises like those offered by Uplift Events.
By taking your team out of the typical office environment and forcing them to rely on each other to get things done in a different context, you will show them the rewards of being productive together. You’ll also make them feel like you notice them and care about their work, because you are investing in their well-being as a working group, and giving them something fun to do for the day. Prove that you’re committed to the team as a manager by taking part yourself.
There are many roles on a project team, and two people whom you may find on your team are the business analyst and the systems analyst. So what do these individuals do and how will they help you deliver the project effectively? Let’s look at some of the commonalities and differences of these roles.
When do they get involved?
The business analyst (BA) will typically get involved much earlier on the project than a systems analyst (SA). The BA will be a key member of the project team from the very beginning, but you might not find that the team needs the contribution of an SA until the systems analysis phase.
What involvement do they have?
The clue is in their job titles! The BA is typically involved in business process work and if the project (and the company) requires it, they will also be involved in strategic level discussions about the evolution of corporate strategy or business requirements.
The SA will have more involvement in the design and testing phase and is typically a more technical role with a greater focus on how the technology solution will work in the current environment and how this will interface to other systems.
Many project managers work with Business Analysts (a BA) on their projects. It can be a very useful role to have on the project team, but the role itself can be quite a mystery to the uninitiated. So, if you have never worked with a BA before, here is a brief introduction to how they contribute to a project team.
What is the BA responsible for?
Different companies view the role of the BA in different ways, so what each individual business analyst is responsible for will largely depend on their job description. However, here are some of the areas of common ground where BAs normally work:
- Researching and investigating existing business systems. This normally covers more than just process or system mapping and can include looking at how the organisational structure works and any elements related to staff involvement or development. This usually involves doing detailed analysis of the ‘as is’ state.
- Identifying the actions (with input from the relevant business users) required to make system improvements. This follows on from the task above and results in analysing and mapping the ‘to be’ (desired) state for the system. This can involve more than simply proposing IT changes and can also involve suggesting areas for more training or redeploying staff so that the whole process/system works more effectively.
- Documenting business requirements. This is a very common area for business analysts to work in, and normally follows a period of requirements elicitation, where the requirements are gathered from the relevant business users and then documented. The BA has to take into account the requirements but also the technical and system constraints.
- Ensuring that was is built maps back to the requirements. The BA can be very helpful during technical and system testing (and early, during any build phase) to make sure that what is being delivered is actually what the business has asked for.
There’s a school of thought among veterans of difficult change management projects that technology holds the key to success. The bigger the programme, the bigger the project management system you need, some would say.
First, some of the major project management systems are massively over-engineered. They include layers upon layers of esoteric functionality that is hardly ever used. If the system it too complex, there is a very real danger that they will end up serving as little more than glorified time recording systems, something that could be knocked-up in Excel in a few days.
Second, these big systems are old. They address change management and project management as if little or nothing had changed over the last 15 years. So many lessons have been learned and new techniques developed in recent times, but very little of this knowledge or new practice is evident in these dinosaur systems. Read more »