Please login or join to subscribe to this thread
As you mentioned it seems like you have no information or KT done for this project and it is not even planned. So you want to get some ideas where to being with.
Considering this I might look for following in the project:
1. I will go through the project charter or scope statement to understand the expected outcome from the project.
2. I will go through the OPL, issue log and risk register of project. This will give me a fair idea about the current status.
3. I will then check for EVA to be more knowledgeable abouy project.
4. I will look into RASIC info to get fair idea about my authority and boundary.
5. Diacuss with sponsor with my knowledge gaps to be sure I am with correct understanding regarding project.
6. Define the priorities and work accordingly.
What does mean testing?. Is the time to validate that "what you need is what you get". Accountable for defining the product chareacteristics and scope is the business analyst. The project manager is accountable for creating the product exactly as defined (project quality). Then is time to take the product scope and validating if it is achieved. Talking in the extemes, I should not take the position if I am not clear of the product scope definition to put clear to everybody how much the project has achieved it which will be validated thans user acceptance test cases to be executed.
Is the previous PM available or can you track them down? They would be a valuable source of intel...
Meet the sponsor and (if separate) primary customer.
As Tarun has said, spend time reviewing the project management plan (all components) and the "living" PM artifacts (e.g. risk register, issue log, schedule, financials).
Speak with key stakeholders including each team member and get their perceptions, fears, uncertainties and doubts.
Hi Robert. You've had some good advice already. I would add that "testing phase just prior to implementation" sounds like a bit of a red flag to me. Testing ought to be throughout and not just before an implementation.
get clear about a few questions
why do they change the PM midstream?
Why did they chose you?
Why did you accept?
Do you understand their culture? Values, beliefs, norms, behaviors, ..
What does each team member understand what the status is?
When is your first milestone you will be in charge of?
What is the business case, what the release roadmap?
Will the releases be functional, geographical or per business area?
- conversations over reading (or people over documents)
- acting over planning (or be decisive)
- achieving results over doing 100% (or be a risk taker)
Wish you best luck.
I'll skip my version of what's already been said, and focus on three things: testing, implementation, and post-implementation support. If this is the first release of a multi-year project, you could be in various stages of planning and executing these at the same time.
Be prepared for testing to take longer than planned. Blockers will be found that take a while to fix that prevent others from working.
Don't wait to start planning implementation. Go through several drafts. Over-communicate. Check for external dependencies - if there will be down-time, who is affected by it? Can they veto your downtime plans?
Case in point - I worked for a company where we were planning a production launch affecting both SAP and the e-commerce site. There was also a product launch in one of our markets that weekend. We moved our date.
Is there a data migration involved? Has the team performing it practiced the migration? Have they done it on a production mirror, with identical hardware/software configuration and services running? Once, during a migration, we had tools that were supposed to allow us to migrate most of an 8 TB database while production was up, and then run the deltas during downtime. A chron job was missed, as well as some third party processes from another system. Two days into the migration, we almost crashed production when they kicked off. We had to stop the migration and postpone the upgrade.
It is not unreasonable to find minor bugs during testing and leave fixing them for after launch, assuming the business approves, in order to launch on schedule. The impact of this, on a multi-year project, is that after launch you may have the same resources 1) fixing bugs found during testing, 2) fixing bugs found after launch, and 3) working on the next implementation. This will affect your schedule. Manage that expectation with your sponsor and stakeholders.
I could go on, but I'll leave some space for other people ;-) Good luck!
Some good advice already.
I'll add that you should find out what standards/governance processes are required for a project to complete and implement as there may be missing project documentation that you will be responsible for. A departing project manager has little incentive to ensure everything is well documented.
Connect with your leads to build your working relationships and get information flowing. Communication is key, especially as you near a release. You need the unvarnished truth in order to effectively manage risks and expectations.
Please login or join to reply