Please login or join to subscribe to this thread
First of all congratulations for getting what you wanted.
Looking at the expectations from your leadership(1200 hours of effort required in 8 weeks) for a project is so unrealistic with 2.5 resources.
Does your leadership team acknowledge that these timelines are very unrealistic and did you try to explain them the situation?If not ,I would ask you to do that immediately and instead of bluntly saying this is not possible ,explain to them why is it not possible to achieve this.Based on their feedback you can think about the next set of steps.
The only and only product that is totally different than any other type of product to create is software. Why? Because what is know as "intangibility". That´s because to deal with software is not for anyone. For example, when you go to people that is creating the product and you ask "which is the progress?" and they say "60%" the question is "how you meassure it?" because sofware is intagible how can she/he meassure it. With that said, dont worry, relax. I worked in software field in top projects on the world (mainly becuase there is a new technology involved then the uncertainty was high) from 1979 and I am here. The problem with timelines, which increase in software field because the intagibility, are estimations but is the same into all domains. Estimations published are not the estimations created, that´s the problem. Remember that the source of all problems are requirements. Then, first thing to understand is what a requirement is. You have two type of requirements: product requirements and project requirements. Project requirements must be created from product requirements. Here comes the first problem: a product requirement, at least a well formed product requirements, is something that allow you to create something. Ambiguity is the evil. People who are deal with product requiements must kill ambiguity. So, the first step, is engage people that will deal with product requirements. Just to rememeber: PM is not accountable for product requirements but in the case you are talking about it seems to me that´s not your situation. If you need more opinions, send me an email to email@example.com. I will answer you with no intention to get from you any other thing than your feedback if you implement what I answered. Regards
While the symptoms you describe indicate a low level of organizational project management maturity, this is not uncommon with companies where salespeople are paid based on the initial sale and not on long term customer satisfaction. In such cases, sales & delivery are worlds apart.
Look after yourself first! No one else will do that if you don't. As a PM, if you are getting near burnout, that will negatively affect not just you, but your project and your team.
Escalate your concerns about unreasonable workloads and mis-set expectations but if they fall on deaf ears, walk away. Believe me it is much easier to find a new job than it is to recover from getting burned out.
Remember that money is a hygiene factor only - so long as you are being paid a decent wage, look for higher level motivators including: autonomy, purpose, mastery and being treated like a professional.
It appears to me that you are being held accountable for the success of the project, based on your statement that “this is creating a ton of stress for me.” It also appears that you were excluded from the SOW creation process.
You cannot properly perform in the role of a project manager if you were not involved in the initiation and planning phases of the project. To state it another way, it is not fair to hold you accountable for the success of the project if you were not involved in its initiation. Now, if you are acting as a project administrator, wherein you are performing scheduling tasks and reporting status, then that’s different – but in that type of role, you would not be held accountable for success.
This situation is a recipe for what I call the PIT (Project Induced Trauma). It appears that you need an additional 1.5 resources based on a straight-line view of the effort, but it is not likely to scale that way in an “enhancement” project. So, if you want to see this through, then (in my opinion) you need an immediate “architectural review” done by a seasoned application architect, as there might be an opportunity to reshape the work-packages and/or refactor approaches to accommodate your timeline.
It’s a tough situation to be in, but if you are truly accountable for the success of the project, then you need to plot a path to success, and if that means bringing in the necessary expertise, then “make it so.” If you don’t get the support you need, and that is the normal pattern of operation, then I would suggest you consider moving to an environment where management enables you to be successful.
Please login or join to reply