Wednesday, January 2, 2019

Project Management Myths: How much do you know?

Project Management or Task Management?

Everyone has been duped. Duped into believing there is a “Body of Knowledge” or a “Scrum Master” or any number of things related to IT project management. There is no Project Management. There is task management. A project doesn’t keep changing - it remains amorphous from initiation through delivery. You have tasks, and you manage those, along with people, expectations, budget, and really everything besides the project. The project is just what people talk about in to have a common reference point. They can only directly talk about tasks, deadlines, and other empirical data/things. A project is a cloud without clear edges, and it moves this way… then that. Sometimes it is by design, but sometimes it is not.

Ayer said if it cannot be proven true or false through experience, it is a nonsensical statement. I think considering a project anything more than a bucket of tasks, people, meetings, and assorted ceremony is nonsensical. You have your phases, milestones, meetings, UAT sessions in one or another regardless of the underlying PLC, but what does this really mean? Project start, do, and end. There are things that people look to in order to recognize a given effort. People need to communicate to make that happen. Ultimately, the effort either passes the test, fails the test, or falls somewhere in between and there is an uncomfortable call where you and the Client try to determine what is fair. Wouldn't it be obvious?

An Agile SDLC removes the need for the “classic” PM and GANTT charts (thank God). However, a Scrum-Master is not enough. You need someone with common sense and communication skills who isn’t afraid to ask questions and is, above all else, good at finding answers and not emotionally attached to anything but the Process and Excellence. Why be emotionally attached to the Process? If you have to ask, I don’t think I can explain it to you.

You either love delivering good working software or it’s a job. It can be both at times, but the passion is what makes you great. If you don’t want to be great at whatever your chosen discipline is, I don’t understand you, but know you are out there in vast numbers. Emotion is key in Project Management and Software Development. You have to care. You have to really give a damn. Day to day, decisions are made pragmatically, but that pragmatism is a tool leveraged by the passionate. Or at least, it should be, in my opinion.

Define features, assign priorities to them, practice RIP or RAD or just plain old iterations and while you do UAT, let the client prioritize and re-prioritize and add features all they want because, in the end, it is their baby. You want it to be yours, and it might feel like yours, but you are babysitting. I don't know… maybe you are delivering. In my finer moments, I like to believe you are performing magic and manifesting chances for ephemeral excellence, otherwise lost in the mist (or something similarly eerie).

Project Management isn’t about deadlines. It is about delivery. There is a big difference - just like software isn’t made of activities, but it is made of features. Management becomes a means to an end and not a science unto itself beyond the fact that it must include an inherent ability to turn itself into something else. What is good for the goose might not be good for the gander. Still, we can try to lump them together for sake of expedience and to sell books on The Process. We impose things like deadlines and estimates to give the illusion of control. While deadlines and estimates can be marginally effective, they will never be as effective as a passion for Process.

People point to Parkinson’s Law and claim that workers somehow manage to take all the time they can to fulfill a task. This is only rarely true. More often, people complete a task in as much time as required. It is simply the definition of what required means that can lead to varied results. Process is malleable. Process is not a set of phases and it is not a templates approach. It is different for each project, each organization, and it will possibly change mid-stream. Process is not pre-defined. It is defined as you go, like your System, and in the end, the code is the functional spec (the path you take is the Path). I have found it best to let the Project reveal it’s Process.

Some speculator I should know the name of but don’t said that he simply removed the excess marble from the statue. I like that ida. Of course, you have to know how to recognize the signs that something is unclear, iterative, risky, costly, or otherwise noteworthy and be prepared to nudge it along and steer it. However, there can be no didactic System of Project Management. In fact, as I said earlier, there can be no true Project Management. There can only be work, workers, money, expectations, and the like. This is not a bad thing. Not at all. And I think the IT community is coming to realize that Project Managers cannot be certified but by experience.