Managing Projects Without a Framework – Part II
Managing Projects Without a Framework – Part II
Marianne Hang, Senior Project Manager
July 30, 2018
Now For Some Quick Wins
In part 1 of this blog series, I introduced a scenario of landing in a project management role where there is no project management framework. The first steps we talked about to help survive and thrive in such a situation were reviewing documentation and building working relationships. Now that you’ve made it past the first few weeks and you’re finding your way, you figure it’s not as bad as you thought and you’ll stick around for a while. To seal the deal, and demonstrate to the client that you know your way around project management, what are three of the first artifacts you want to deliver to really put that grey zone behind you? My recommended choices provide you with three strong pillars in your foundation for a successful project and show benefits of that foundation clearly to your client. Each document is also what we call a *quick win*. This means that early on in the project you provide a completed artifact that helps to move the project forward – while also showcasing your skill set.
This is a given. I like to say that the Project Charter is the bible of a project. It’s the document that starts and ends the initiative – the document you’ll refer to throughout the project lifecycle – and without which, neither you nor anyone else has a clue what to do. Oh, everyone may think they have a clue, but you as the Project Manager know better. You know that it’s the Project Charter that is going to take everyone’s clues and put them together into a document that is comprehensive, cohesive, and aligned. Just as important, it’s signed off by your Project Sponsor and others so that the individuals with all the clues don’t go off on their own tangents. Writing a Project Charter in the early days of a project is a scary proposition, so it’s often written too late to be of full value to the project or its not written at all, especially if there’s no project management framework in place. If you don’t have a Project Charter template, ask your PM colleagues, or one of those professional associations like the Project Management Institute. You can also grab one off the internet. This is your first draft so don’t expect yourself to write a complete or final version. Many Project Managers expect this and then feel so rightly overwhelmed that they put off writing until it becomes a red flag – and as such, they never become comfortable or confident in writing a Project Charter. In Stage 1, you’re looking for not much better than + / – 100% for your KPIs and you probably already know, or can find out by talking to stakeholders, much better than that. Make sure you hit every part of the Project Charter, even if it’s only at a very high level. This document is the first document that touches pretty much every subject that needs to be further developed in the project so by getting some information into every section, you’re helping yourself by creating a start for many other documents. Remember, the Project Charter is an evolutionary document that serves a variety of stakeholders. If you need help writing this document, one of the best resources to engage early on is your IT Architect. This resource is likely to have both a strategic and tactical view of the solution the project will implement and the deliverables needed to get there.
Once you’ve got the first draft of your stage 1 Project Charter complete, you can get to work on your Project Plan. If you know nothing else at this point, you know you’re going to have the usual project stages – so some kind of stage 1 for plan, stage 2 for design, stage 3 for build, stage 4 for go live, and stage 5 for close. You know the start date of the project – either when you started your role or when you started the Project Charter, or you’re given a date. You know when the project is supposed to end – realistic date or not, use it for your first draft. Now you’ve got the thing bookended so start making educated guesses as to where stages should fall within that space. Planning could take a month or more if everything is pretty much set in terms of what the project is supposed to do. Design could take two to three months or more, depending on whether a solution is identified and a vendor needed – here’s where having an IT Architect is of huge value because they can provide tons of help in forecasting time for technical work. Build is usually the most time consuming phase so maybe you need three months or more here, again depending on what solution you’re delivering. Testing, training, and go live can’t be rushed so ensure you don’t cut stage 4 too close – say two months to mitigate the stress inherent in moving a solution to production. Then don’t forget you can’t just run away once the solution is live – you need a final stage to provide a warranty period, get documentation finalized and signed off, look after financials, and complete a Project Close document that is signed off – so at least a month here. This gives you high-level chapters between your bookends. Now think about a little more detail based on what you provided in your Project Charter. This is where a template helps – it should provide all the details and then you eliminate activities instead of having to worry about what you missed. Estimate time and resources based on best practices, previous experience, and then go to the resources who’ll be doing the work and get information from them. Book working sessions with the right individuals to get work done – it engages them early on and builds working relationships – as well as demonstrates that you’re a team player. It also helps dispel discomfort the Team may have in the early stages of an initiative, and when the work is done, everyone feels a sense of accomplishment. You made the plan and led the team to these quick wins!
With your Stage 1 Project Charter and Project Plan in place, you can put together your Stage 1 Project Budget. Again, so as not to feel overwhelmed, remember you’re going for +/- 100% accuracy at this stage. Don’t expect yourself or anyone else to know much more than very high-level estimates at this point. The budget is a living document, just as the Project Charter and Project Plan, so you’re going to be fine tuning them all on a regular basis as you get more and better information. Identify what you know – don’t get caught up in what you don’t know at this stage – and use a good template. You may have been given a budget at the start and if so, this is great because you’ve got a limit to work within. You’ve either been given a start and end date or you’ve forecasted both in the Project Charter and Project Plan. Use those dates to forecast resourcing costs by what you know at this point as to who’ll be charging to your project. As a PM, you have a sense of what type of resources tend to do what type of work, at what point in the project lifecycle. For example, you need an IT Architect in stages 1 and 2 where solution requirements drive solution decisions, which then drive solution design. You need subject matter experts and solution developers in stage 3 where solution build is the focus. In stage 4, solution build is vetted and prepared for go live so you need testers. In stage 5, the solution is live so you need operations resources to transition to. For equipment costs, go to the source when you can – your architect or approved vendors. Complete what you can, ask questions to address gaps, and then see where you’re at. Now you have a first draft that is much less intimidating than a blank document and you can move forward on filling in unknowns and fine tuning. The sooner you present the budget, explaining that for stage 1 its +/- 100% and you’re working to fine tune it, the sooner your stakeholders get on board the process of needing to provide you with information to do those tune-ups. Talk about your rationale for arriving at the information you entered – this helps generate that all important confidence in your abilities early on.
You and your Team should be feeling like you’re getting a handle on the project now – you’ve got working relationships in place and key documentation completed that defines your go forward plan. Continue to build those working relationships and develop supporting documentation, now that you’ve got a strong foundation in place for both. In the third and final part of this blog, I’ll talk about how to keep your and your Team’s momentum going with three important actions that you’ll want to implement throughout your project lifecycle.
Ms. Marianne Hang is a Senior Project Manager affiliated with IT Architects in Calgary, Alberta. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, and the deployment of leading-edge technologies. If you require further information, Marianne can be reached at firstname.lastname@example.org or 403-815-7505.