Nenad Trajkovski

Hi,

many times I heard talking about big and small Projects. Many companies have different procedures for them. Of course procedures are lightweight for small Projects, and heavy for big ones. But, I am not going to talk about different procedures. I will talk about how recognize those Projects.

Almost every company which make differences among big and small project make it by the:

• Budget – or how much will it cost?
• Time – or how much will it last?
• Resources – how many people are going to work on it?

And, for example, decision is:

• If the Project is under $100.000 it will be considered as small, otherwise it will be considered as big
• If the Project is under 3 months it will be considered as small, otherwise it will be considered as big
• If the Project is going to be done under 10 people it will be considered as small, otherwise it will be considered as big

And, frankly, I do not agree with that. YES project can be measured with those parameters, but think about this: RISKS. From my point of view Project is big if it is risky. Let me explain that theory. Let’s say that you are going to upgrade 10 computers to the latest version of operating system. And you need 2 hours per computer. And you are going to be payed $500 per computer. And you need only two persons to do that. So, this is cheap, short, and not people demanding project. According to parameters mentioned above, it should be consider as small. BUT! What if those computers serves as as front end computers in the bank? What if mayor application is running on those computers. And, finally, if this application won’t work, you will get extremely angry customers. In other word, what if this upgrade project is risky? And it is, no matter of budget, time and resources. See where am i pointing at?

On the other hand, if you sold ERP system to company which is subsidiary of another Company. And it follows all processes and procedures as the main company. So, new ERP system is, more or less copy – paste Project. BUT, since we are talking about ERP, and licenses are expensive, we are talking, for example, about $500.000 budgeted Project. Is it big? Well, not exactly.

So risks, risks, risks, are always the primary measure when you think about your Project as big or small.

To be short, and jump in the conclusion at once. If your project is risky, no matter how small your budget, timeline, and resources demands are you should consider it as big!

Regards,

Nenad

Hi,

as a Project Manager I red thousands and thousand articles about Project Management. I focused on tips “how to Manage Projects on right way, and how to get Projects done” and I found a lot of useful and helpful articled. BUT! No in most of them you will find what must be done. And this is great. But, how should something be done? Those answers are usually great, but general! What do I mean by that? Let me give you some examples.

1. Establish good relationship with sponsor
2. Establish good communication with all stakeholders
3. Make a good plan
4. Communicate with the team often
5. Raise problems early
6. …..

You are all aware of that. All those tips have one single question in common, and this is: HOW? Again, examples:

1. HOW TO Establish good relationship with sponsor
2. HOW TO Establish good communication with all stakeholders
3. HOW TO Make a good plan
4. HOW TO Communicate with the team often
5. HOW TO Raise problems early
6. …..

If we ignore problems like Force majeure (Like hurricane or earthquaqe), and technical problems (like server crash), you will see that all challenges and problems are related to the people on the Project. So, when you read tips remember that there is no such a thing like: “One size fits all” tips.

Let me give you example. Some people want reports daily, and they are unhappy if they do not get them. some people like reports in PowerPoint, some in Power BI, some in Word, some in MS PROJECT, and some of them want to have a meeting when you will tell them how is your project going without using single tool. And they are all stakeholders. What will you do? Make multiple types of reports? One for each of them. Or would you pick the most important stakeholder (whatever “most importnat” means) and make just one type of report for this particular stakeholder? Do you want a tip? Real tip? It is: “I do not know!”. you should see what kind of persons are you dealing with. Are you dealing with stubborn one, or reasonable one. Can you show or convince them that making many kinds of reports are waste of time and money? Or not? Do you see where am i pointing at. PEOPLE!

Finally – the Culture differences. Today Business as usual is that you will have a Project surrounded with people around the globe. And they are different. with that I do not mean that some nations or cultures are better than the other. NO! Not at all! I just want to point out that what is common and usual in one culture, is unacceptable in other. For example in one culture that is usual thing to start the meeting with talking about politics or about family. In other that is considered as improper. And this is easy to solve if you have people from one culture in one meeting, and from the other culture in other meeting. but, usually you will have people from different culture in a single meeting in a single room.

I have 30 years of experience in Project Management. And if someone will ask me what are my tips I will say:

1. Always act as a Professional. This is your job. Never, ever take ANYTHING PERSONAL
2. Approach to every single person no matter of his/her role (Sponsor, Stakeholder, Developer, ..), differently. Yes, this is hard. But every person in this world is different. Respect that!
3. Remember that every Project is unique, so do not use same procedures and approaches in every single Project
4. Be aware that with some people (or many) you will have a problem to make understanding. You will. In every single project you will have at least one person who is hard to deal with. YES. HARD. Do not complain. Again, that is your job.
5. Hope that you will have a luck, but be prepared that you will not, and expect problems.

My 5 cents

Regards

Hi,

today I’m going to describe some problems with Processes and Procedures within Projects. First of all what is Process, and what is Procedure?

A process is a set of activities that interact to achieve a result. A procedure is a document written to support a “policy directive”. A procedure is designed to describe who, what, where, when, and why by means of establishing corporate accountability in support of the implementation of a “policy”.

Now, for managing Project almost every company has prescribed Processes and Procedures. And that is good. Without that one severe problem will occur during the Project. Every single time when new Project starts, Project Manager and the Team will have to start from the scratch. With this said I mean that instead of Planning the Project, PM and the team should start with: “How will we do it? Which tools should be best, which approach should be best, etc”. and this is waste of time, which they  do not have. On the other hand, if there are Processes and Procedures prescribed for managing Projects, PM and the Team will be familiar with them, and therefore they will know exactly how to manage the Project upfront. It doesn’t mean that it will leave them without usual problems in the project, but it will help you with Planning, Execution, and most important, Monitoring, Controlling the Project and when problem occur, fixing it!

As usual, there is always – BUT! I saw many time that Processes and Procedures are burden to the Project. why is it so? According to PMBoK: “Project is temporary endeavor undertaken for creating unique product, service or result!”. U N I Q U E! There is no such a thing like two SAME Projects. They can be similar, but they cannot be SAME! Therefore each and every Project should start with the simple, but important question: “Which Procedures and Processes should we change (adopt), which we should throw away, and which must be added as new ones for this particular Project?”. Procedures and Processes are not written in a stone. They are here for help PM and Project Team, but they should be adopted to every single Project. If Management insists to use every single Process and Procedure for every single Project, then they are on the wrong way.

Finally, PMBoK- The Project Management Body of Knowledge by PMI. It is framework which has a lot of Procedure and Processes inside. But also you can find inside remarks which says that they should be used if you need them, and how you need them. Of course, there are some exceptions. For example, Project without Project Charter could not exist, neither without Project Plan, WBS, etc. But other parts should be used if, and how you need them.

Regards!