Do you always delivery 100% successful IT project?
Then you are doing something wrong!
Here is why:
A very important part in any project is to find what worked well and what could be improved, in other words, identify the lessons learned. If you feel that there is nothing that can’t be improved for your next project you are on a downhill battle.
If you don’t move forward, you are moving backwards.
In this article I will share with you 17 of the most important lessons learned you can take as an IT project manager.
Requirements, requirements and more requirements
![Bright man writing down requirements.]
Bright man writing down requirements.
Unfortunately, it is quite common that IT project starts like this:
Some very bright men and women sit down together and begin to write down all of the requirements that they can think of for the new software/system that that are so eager to see developed.
But, what do you think usually happens with this approach when the project is coming to an end?
One, or a combination, of these three outcomes usually happens:
- The end results are lacking a lot of the defined functionality
- The need from the users have changed
- Everything is developed accordingly to the requirements and the needs has not been changed.
In all honesty, the first two outcomes are much more likely to happen than the third.
Let me tell you why:
Writing down all the functionality for a software/system and then leave everything to the developers until they say it’s ready for testing is generally a bad idea.
With that approach you have no possibility to verify that you are on the right track, make changes or come up with different, better functionalities until everything is ready.
Instead, you should focus on specifying just enough to keep your team to be busy for 2-4 weeks.
When those weeks have passed you should be able to test and review what has been developed.
After that you can define changes to what has been developed or new functionality that you want in the coming 2-4 weeks.
By implementing a project in short iterations of 2-4 weeks you will have a much more agile approach, which in the end will increase the likelihood of your project to be successful.
My Lesson Learned
I once joined a project as the project manager for the final development phase of a new IT system.
There, I discovered that some of the specifications were 4-5 years old, and still had not been developed and approved.
This caused a lot of frustration for both the customer and the supplier.
Here is how I solved it:
We started to follow the suppliers sprint plan, which meant defining what functions that should be developed every two weeks.
After each iteration we had the possibility to test and make changes to the functionality. We also released some of that functionality to the live environment once per month.
By implementing this agile approach we didn’t have to worry about those old specifications. The new specifications came in regularly to the backlog, were prioritized, developed and released.
Tərcümə , tərcümə və daha çox tərcümələr
![That's not quite right.]
That’s not quite right.
Yes, that is what a lot of customers are saying when they review a product.
I’m talking about lost in translation issues.
Since some developers don’t speak the same language as the end users there might be some text in the software that weren’t translated correctly, or not even translated at all.
This is a minor issue, but can cause unnecessary discussions.
To avoid this, the supplier must take greater care and put in place routines for verifying that all text that should be translated is.
Ideally, the project should install a role which has the responsibility to verify all translations.
That roles responsibility should also include the task to define what common terms really mean, and also how to spell it so that everything looks the same throughout the software.
Let’s agree to disagree
![Let's agree to disagree.]
Let’s agree to disagree.
There are usually many stakeholders involved in IT projects, and everyone has their own opinion on how things should work.
That means that whenever there is new functionality to be specified, you have to talk with all involved and relevant stakeholders and come to an agreement.
When you have set up a meeting to discuss the new functionality one of the following scenarios might happen:
- All parties agree and the functionality will be developed
- The relevant persons didn’t show up for the meeting and thus no agreement could be made which delayed the process
- The relevant persons couldn’t come to an agreement
And here is how you can manage those three scenarios.
- Grab a cup of coffee, sit down, and smile
- Arrange another meeting and make it abundantly clear who should attend the meeting and their responsibility
- If they couldn’t come to an agreement you have to escalate the issue to the steering group and they have to take a decision
My Lesson Learned
I have experienced all three scenarios in almost every project I have been involved in.
My big lesson here is about meeting organization.
In meetings where thing are to be discussed and decided upon I always do these four things:
- Make an crystal clear agenda
- Timebox each topic
- Assign responsible persons for each topic
- Invite the persons with the right authority
By doing these four thing I make sure everybody shows up and are prepared. If we can’t come to an agreement the person who has the final say are also in the meeting.
Functions first, not processes
![Women writing a process with empty boxes.]
Women writing a process with empty boxes.
That’s not quite right.
Processes should come first, not functions.
Sometimes you can let the project spend a lot of time defining a functionality, get it developed and put into production only to realize that it doesn’t reflect the reality of how people work.
Why does this happen?
Because you focused on functionality before processes.
Just as fine any functionality is we really need to understand why and how we want to work before focusing on defining functionality.
My Lesson Learned
Whenever I hear a lot of confusion and discussion about a new functionality a small red flag raises inside my head.
Then I ask the question if the functionality has any connection to the work process, or if there are any work process defined at all.
It is much better to delay a functionality and wait until the process is ready than to rush into developing something that is not fully understood.
That’s not what I asked for
![Guy received what he didn't want.]
Guy received something he didn’t want.
Describing and explaining things face to face is quite difficult.
Want to make it even harder?
Try to do it in writing or by a crappy phone line.
Add to that possible language difficulties and it’s a miracle that you could get anything done.
The dialog between the customer and development team is crucial in any project.
If that communication isn’t working, you will experience a lot of problems.
So how can you make the communication work?
By using these techniques:
- Get the supplier and customer together for face to face meetings
- Involve the actual programmers in the discussions
- Always ask the supplier to document their solution suggestions, not only confirm that they understood it verbally
- Don’t be afraid to book extra meeting to discuss the functionality
These four techniques will help you minimize the “That’s not what I asked for” into “That’s exactly what I wanted”.
Was that my responsibility?
![Don't point at me.]
Don’t point at me.
When something needs to be done you must be absolutely clear who has the responsibility and own the task.
Are you familiar with that great feeling you experience after a productive meeting?
Everyone showed up, participated, decisions and plans were made.
But, at the next meeting nothing was done.
I thought everyone understood what they should do.
Probably everyone understood the task but no one were officially assigned to it, so it didn’t get done.
This brings us down to that roles and responsibilities in projects must be clearly defined, documented and communicated.
Communicated not only once, but as often as needed. There is nothing wrong with being overly clear about who is responsible for what.
My Lesson Learned
One lesson learned from this is to use a good system for task delegation.
I have often used JIRA for this. In that system you can assignee responsibility to a specific person which makes it 100% clear who has the current responsibility for the task.
But just make sure you don’t end up in a “JIRA assignee war” where people throw the responsibility back and forth at each other.
In JIRA you can also add a lot of other useful information around a task like component, affected version, watcher, assignee, reporter etc.
Where is John?
![Anyone know where John is?]
Anyone know where John is?
Getting people to participate in meeting is not always an easy task.
The decline reasons that pop up in my email client are plentiful; they are busy, on vacation or simply doesn’t want to participate.
When we are a maximum of 3-4 persons it can easily be solved by rearrange the meeting time.
However, when you have already scheduled a day and time and invited 10-15 people rescheduling the meeting is not always possible.
So, how do you get maximum participation for those kind of meetings?
Clear agenda and expectations from each participant
Make them present something of their own in the meeting
Don’t invite persons that doesn’t make point one or two
If they decline, follow up with a phone call talk about their reasons for not coming and see if it can be solved
Meet the meeting expectations and make something good out of the meeting so that the participants will be more inclined to participate in the future
Decisions from meetings – let’s (not) ignore them!
![Follow up decisions.]
Follow up decisions.
If you do proper preparations you will increase your chances of having a great meeting.
But the work doesn’t stop there, you must put in at least equal amount of work after the meeting.
Your two main responsibilities are:
- Send out a meeting review
- Follow up on decisions made
Number two on that list is crucial.
Because if you don’t follow up on what was decided, people will start to feel that your meeting has no value, they will start to think they are a waste of time.
And eventually they won’t like to participate.
So, it is very important to follow up on what has been decided so make your meetings a true success.
Listen to me!
How do you know what kind of functionality you should be delivering?
You ask the users! (Unless you are Steve Jobs)
But that was the easy question. The tough one is: How do you ask the users?
One obvious way is to send out a survey. But you should also consider interviewing your end users.
Your game plan should look something like this:
- Identify users that have an interest in your project/software
- Conduct 30 minute interviews with them
- If possible, put them in charge of defining the functionality, explaining it to the supplier and also testing it
This will give your chosen users a great feeling of involvement and make them excellent promoters of the project.
I have my own system
![I make my own decisions.]
I make my own decisions.
As a project manager you will be in charge of setting up the plan, framework and techniques used for your project.
That is an essential part of your job.
But from my experience you might run into people that have their own way of doing stuff, and they are not interested in changing that.
And that is OK, you should be flexible and leave some decision to the single project members to keep their locus of control high and thus also their motivation.
My Lesson Learned
One small example is JIRA vs Excel.
A member of one of my teams didn’t like JIRA and used her own system of tracking tasks in Excel.
We tried several times to get her into JIRA but our attempt didn’t succeed.
But in the end of the day, did it matter?
The answer is both yes and no.
Although she didn’t always have the latest status of the tasks from the development team, she stayed motivated and worked hard with her tasks by making the decision to use Excel instead of JIRA herself.
If we had to force her into JIRA she would have gotten demotivated and we would have had a bigger problem on our plate.
What’s the status?
![It's a dashboard, very useful.]
It’s a dashboard, very useful.
There is usually a lot of people involved in a project.
And most of them are interested in getting the right information and status regarding your project.
From my experience these are the best way for informing others of the status:
- Set up a high level overview of the project on a big wall
- Use digital dashboard for a detailed status
The high level overview is meant to show everybody the road-map and status at the general level.
This will enable people to just swing by and have a look, this will also give you the opportunity to strike up a conversation with the them easily.
The digital dashboard is for creating a more detailed status of the progress. This is kept digital since the changes here happen more often so it would be a full time job to reflect all changes manually on a wall.
Loading, loading, loading…
![Just wait a bit more...]
Just wait a little bit more…
People are impatient and people don’t like to wait.
There have been many studies published about for how long people wait until they get frustrated and leave a website/software.
So, you should really be focusing on building a high performing system. This should ideally have been defined in the project contract, with for example the acceptable average loading time for a user.
But in my experience the performance issue is largely ignored until it becomes a problem.
But then it is too late.
Your system will be the cause of frustration and will get a bad reputation of being slow and not very usable.
But whatever approach you choose make sure you make it an essential part of your project.
We got hacked!
![Be aware of hackers.]
Be aware of hackers.
An often overlooked part of an IT project is the security.
99% of the times this isn’t a problem. But when it does become a problem, it becomes huge problem with severe consequences.
All it takes is a decent hacker with evil intent to break your system.
So, you should really involve security testing as an integrated part of your project. They way it should work is two-fold.
For one you need to educate the developers in how writing secure code. And on the other end you need to arrange proper penetration testing of the system.
And don’t forget to also test social engineering techniques.
It is ready for test…
![Time to test!]
Time to test!
When a developer finished developing a task you will often get a short message saying it is ready for testing.
But even though the tasks has been clearly defined and what was done is easily understood by the developer the person who are to test it needs more information of what has been done.
Too often I hear that the person who is about to test doesn’t know how the supplier solved the task and how to test it.
This boils down to bad communication.
Arrange a meeting where the developers can present and demo the new functionality. And only after that the customer can test and verify it on her own.
Letting the developers demo the functionality themselves also adds extra motivation for them to do some testing on their own beforehand. It also adds an opportunity to identify issues together at the demo meeting.
Ain’t nobody got time for that
![A lady with no time.]
A lady with no time.
Usually people involved in a project are not engaged full time.
They have a lot of other responsibilities and work to do.
So, when you ask them to do something project related a common reply is that they don’t have the time.
If they answer they don’t have time, ask if there is anything else stopping them, and when they answer ask them again.
Keep asking until you get the real reason.
Because not having the time is not a valid answer. It is all about prioritizing, and the real reason you want is why your project is not prioritized.
My Lesson Learned
I had some trouble getting people to take the time and test in one of my project. What I did to solve it was to book in a meeting with them where we sat down and tested together.
This created a time block in the calendar dedicated for testing. If it weren’t for my involved they probably wouldn’t have taken the time for it.
And in the end they started doing it on their own as well.
This method can also be improved to include more people and do a full day activity fully decided to whatever task that need to be completed.
People go outside agenda during meetings
When you have a meeting with other people you will have to deal with a managing them to stay focused on the agenda.
I think we have all been in meetings where the majority of the time is spent listening to some rant, or what somebody did last weekend.
This can be important and interesting – but to talk outside the agenda is often the root for a lot of frustration and causes a bad meeting culture.
To avoid this you need to have a clear purpose and agenda for the meeting. And you must not be afraid to cut people off when they freestyle into something outside of the agenda.
But if the topic can be relevant in another setting you can write it down and follow it up.
However, you should make room in your project for people to speak freely, and also make sure everybody speaks pretty much the same.
This creates a psychological safety in your team which is one of the most crucial aspects of creating a high performing team.
But there is a time and place for everything, use special meetings where it is allowed to “freestyle”.
Stakeholders are not involved
In the beginning of a project, one of your tasks is to identify the stakeholders.
Unfortunately, sometimes you identify key stakeholders whom does not participate as much as you would like in the project.
This can cause problems in the long run since they might have a lot of authority, but you won’t get their input until the very end of the project.
To solve this make a small plan on how and when to involve these key stakeholder and serve them the information they need.
This will naturally be a part of your communication strategy. But make sure it is followed and that it works like intended.
What’s your lessons learned?
What’s your take on these lessons learned?
And what are your own lessons learned?
Let us know in the comments below. .