I have worked with customer C-level, Directors and Program Managers. communicating progress, issues and risks, managing against planned budgets, plus mitigation options and activities on both vendor and customer sides of BSS and OSS system implementations and upgrades.
As well as direct management of projects delivery I have both co-managed and supported bid management on the short deadlines with changing and conflicting requirements and expectations.
Execution: A lot of the entrance into practical execution of Project Management today is predicated upon whether you can follow the Prince or PMP methodology, whether you can quote the WBS or when a Risk turns into an Issue that you can quote the process. Nothing could be further from the reality and truth, because those project managers, however smart technically, are destined to be shuffling planned events and milestones around a schedule until they day they wake up. If you don't understand, I mean really understand what the project is trying to do for the business and how, then pack up and go home, is my view.
Experience: Project Management demands more EQ than it demands IQ. Knowing how things will play out, seeing the way the business is moving, gathering the sentiment of the key contacts in your key circle is where the message and the warning signs appear - and where you need to act first. It used to be called Heading Them Off At The Pass in cowboy movie speak. It's being ahead of the game, being in touch with the leading messaging and acting upon it - and making sure that your (my) schedule is not what I call Planning-Backwards, in other words revising the schedule with foresight as a result of decisions not in spite of them - so that you know the true and nett effect of a change before the decisions on direction are made. This is all about connectivity and Emotional Intelligence (EQ).
Schedule: I prefer to run projects from a realistic project schedule estimated and built from the multiple teams at the start of the work, even if this goes sour later. Starting out with a stretch-schedule is doomed to failure and burnt out people. This 'reasonable' approach is essential, along with having this formally agreed across the program and with the customer and their engagement teams. Ensuring that project officer's schedules remains tenable, realistic and agreed with programme manager's budget in dollars and timeline remaining off-limits for project officers unless approved
Communications: My standard Project Communication process cycle is in driving weekly Escalation focused project and program meetings (and not Status) - I expect you to be doing your job as part of the program if you are attending these meetings - I want to know when it's off-track, not that's you're doing your day-job. The best method in my experience is the daily 15 minute stand-up meetings to force clarity of the top issues, get them to bubble to the top, get interaction happening and to get the problems serviced or escalated.
Stakeholders: Stakeholder management throughout the program (which is most often Business Teams) ensures that their support before the program is in full operation and their guidance during execution is mandatory. Anyone wandering off to look at shiny new things needs to be quickly brought back to the table. Variance or change must be recorded and notified at its earliest and a mitigation agreement or a post Day 1 activities plan initiated and a schedule agreed beyond original scope. This is essential so ensure that the agreed scope can be delivered on time. The truth is that this is never so clean-cut and critical functionality or capability is required at short notice as the market demands change during development and testing. This is where and when I earn my keep in managing and mitigating to meet the revised requirements and target.
Change: Telecommunication and Banking businesses are well founded in old methods and processes, although the customers and markets now demand more project flexibility and faster delivery. Reluctance to change from original project scope is endemic in development and delivery teams and not seeing as benefiting their completion. Hence the project manager must try and be everybody's friend however tough the message within change management.
Budgets: I have managed project budgets from $10k for change, up to $20M for projects. My preference is to use Earned Value to capture and manage the spend profile and budget against planned targets allows continuous cross-checking for any under or over budget events. My base expectations of +/-8% are within expected margin, however working with a broader +/-15% margin ranges and reporting when the 8% marker is transitioned allows for more immediate action Runaway is well known in software projects and +35% and up is well known before first alarm bells are rung. Close monitoring and driving development and testing teams is essential following the 8/80 or 4/40 reporting of time spent-vs-outputs met to monitor for success.
Measurements: They say if you can't measure it, it's not worth knowing. Snapshot figures are useful when reviewing against targets, but the rate of change and the progress towards they target should always be on-hand, be graphed and analysed.
Testing: I have managed a full escalation Triage room comprised of multi-vendor teams and onward third parties for a major Tier 1 operator across multiple time-zones with vendors from multiple continents. This has given me insight into the world of Testing and its multiple competing complexities. As mentioned elsewhere, knowledge of the nuances of cultural differences and use of clarifications to revise communication and expectations within escalations and senior director collaborations is critical.