Do we need project management in IT projects? Of course. But we have to manage the amount of management needed and simplify the way to perform it. The purpose of this blog is to share some ideas and impressions about the needed degree of formalization. And in fact, project management is more or less an art. You have to feel it. Like so many other things in life. Amongst others, the correct mix of formalization and freedom leads to a lovely piece of art.
The fashion project has just started. Even Sandy, the customer project manager is a bit uncertain. Becoming familiar with project approaches in general is not so easy. Applying predefined project formats is also not. You, as the IT consultancy project manager, can reduce all anxiety in the beginning of the project, by organizing a splendid kick-off meeting. Involving all stakeholders from the very beginning is key. Also formalization with predefined templates is important: blueprint templates, workshop templates, list of modifications/outputs/interfaces, budget follow-up sheet, status and steering meeting formats… That way, our fashion company instantly feels the project approach covers a real methodology. If the customer is somewhat impressed in this stage, it’s good! Mach Schau! And everybody gets the feeling of a framework being there.
Your customer’s culture and the nature of the project determines the number of templates. In small projects, we don’t need too much of them. In the beginning templates should become living documents. A reminder towards people not filling in the templates according to the rules could help. All these actions create the atmosphere of the project being started. Also informing people about the budget status already at the start of the project is a good idea. By doing so, everybody is aware that their actions are related to an available project budget.
Bottom-up: No control freaks, please!
But being a control freak is also not good. Each project is different, as is each customer. You deal with various personalities at your customer’s side. Let’s come back to our example of the predefined project templates. Assume the customer project manager Sandy starts with her own list to handle issues. Which is not totally conform the standard predefined tools for listing issues you normally use. If you feel Sandy likes to work with this list – and it contains some goods aspects, why not incorporate some of these aspects in your predefined templates? But very important: in the end, there should only be 1 issue list! This is again the top-down action needed then. That way you will see that the initial framework is not applied for 100%, but the slightly modified format which replaces it, will become a real living format! Understood and accepted by everybody. And with input of several new ideas. Keep the good ones for the next project!
Lock them up
Formalization to keep control of the issues is really important. But in the middle of the project there’s a hard interface topic with a needed shop-floor system in production, where fashion customer key-user Matthias and IT consultant Cindy are asked to sit together until the problem is solved completely. You know their time is limited and they are both eager to immediately start solving the issues. Without a lot of administration. So you agree that they don’t communicate to you for 2 days and only the major issues left after those 2 days are listed on the issue list. In the hope there are not a lot of issues anymore left to handle administratively.
Fifty shades of grey in the scope
Scope discussions always have fifty shades of grey. The blueprint phase is aimed at defining all the customer’s needs. This blueprint phase also includes defining the needed additional out of scope topics (compared to the contract). Of course there are formal documents foreseen, which should be signed before starting an out-of scope layout, interface, real modification… But even if you did all administration formally, scope discussion could pop-up when you really dig into the interpretation of one particular detail within an already approved change request. Also there it’s more or less an art to evaluate if this detailed topic is really suitable according to the spirit (“soul”) of the blueprint/additional change request or not. Everybody is aware that the overall lead-time of the project is important. To keep this deadline, you could exceptionally decide to already start the programming of the detail under discussion (within the agreed change request). Even without formal approval. And you could decide to discuss this topic in the next steering meeting. This is not the common way to work, but in some occasions it could be needed to speed up things.
The lost son
At the other hand, assume you are really convinced that Hans is not at all following the rules and is not at all reporting correctly to project management even for severe topics. In that case a confrontation is inevitable. Bottom-up doesn’t mean total freedom. It’s finding that suitable equilibrium which is different for each project. Everybody receives freedom but should be mature enough to handle this.
The X factor
Final project happiness appears when the X factor is born. You have to feel the “soul” of the project. At a certain moment in time you get the feeling that everybody feels home within the project. Actions are taken, tests are done… The tools are used but nobody is talking about the tools anymore. They just became “tools” in the background. More and more you get the feeling that customer project manager Sandy and her team are working independently. When the project go-live is there, your role as IT project manager is critical to be present in case of problems. But pulling all the time is not needed anymore. A month after go-live you are not present anymore on a regular basis, which makes you happy. The project is delivered! But you as IT project manager stay a trusted partner with a lot of conceptual knowledge about the project. Project management is more than administration.
Do you want to share ideas about this blog? Please let us know!