While the PMI would like to believe that every project is clearly defined, with identified stakeholders, a detailed scope, and a realistic timeline, most of us know from experience that projects rarely work that way. To add to the complexity, IT projects can involve a variety of specialty areas that encompass vast and varying knowledge sets (Java coding, data warehousing, business process development to name a few). For the average PM, it is impossible to know it all. So, what do you do when you are asked to manage a project that is not completely scoped or is outside of your knowledge area? You start with what you know and learn as you go. Or, as a client reminded me every time she stuck me on a new project with a different team of experienced architects or seasoned product owners, "Fake it til you make it."

My colleague, Kristin Arais, wrote a fantastic blog about being the non-techie on technical projects, which I can relate to very well. So, when I am working on a project outside of my comfort zone (e.g. my first agile-based software development project after focusing primarily on waterfall -based system implementations for a few years), I find it helpful to start with what I know.

1. Identify the stakeholders – This can be the product owner(s), the business manager, the executive giving the presentation. Don't get caught up on titles, don't be afraid to think outside the box, and be sure to make a list. Finding out who cares about the end result of your project is vital to the project's success. Be aware that your list may change as you progress.

2. Understand the "timeline" – I know this sounds trivial, but ask the person(s), who cares about the result of the project, when he/she needs it completed. I put "timeline" in quotes because I have learned to expect different answers from everyone I talk to. Add the answers to your list and move on. Don't worry; determining if the timeline is realistic is included in a later step.

Note: Not all projects will have or follow a project plan. All projects WILL have something resembling an end result that will be required at some point in time. You need to have an idea of both, but neither may make complete sense to you at the beginning. THIS IS OK. Ask the questions, write down the answers, and keep moving. If you start with what you know, you will learn as you go. But you have to start somewhere.

3. Know your team – The team is your source of knowledge for the project. If you have to select the team, refer to Kristin's article for advice on surrounding yourself with the best people. In my experience, for projects outside my area of expertise, the teams are usually assembled. Trust that the members have been chosen for a reason, and then get to work figuring out said reason.

Learn who each member is and what they have done. Gather what they know about the project, what they believe are the goals, and what they expect to contribute. (Remember your list of stakeholders and timelines? Make sure your team knows them too. Your team will be able to help you understand who the key players really are and determine if your project timeline is realistic.) Understand how each member communicates. Work to uncover their strengths and weakness and learn how each fits into the larger group to which they belong. This is a process that will continue during the life cycle of the project. Don't be afraid to ask a lot of questions and even ask them multiple times. You have a lot to learn. These are the people to learn from.

Note: Be careful not to start or stop with what each member "knows." You need to dig deeper. You may not be able to dig too far at the beginning, but if you keep asking, you will learn as the project progresses. Do not stop trying to know your team or your project better.

4. Start communicating – I would like to say you should develop a communication strategy that fits how your team best communicates, which you should have identified (or be in the process of identifying) in the last step. But it is very likely that you do not know this yet. In which case, pick an approach and modify it as you learn more. One thing is certain; your team needs to communicate with you, with each other, and with the stakeholders. So put a process in place and start communicating.

Note: This could include daily 15-minute stand-up meetings (i.e. scrums) and/or weekly 1-hour checkpoints. It may involve a team chat room, a shared document repository, or a group wiki. If you are jumping into a project with little to no ramp-up time, don't be afraid to try different things until you find what works.

5. Manage your time – We all know that you must effectively manage your team's time to complete the project efficiently. We also know that this involves more than just managing the tasks and deliverables and often looks different for each project and team. So, again, it helps to start with what you know. You know that a meeting is more likely to be productive when you know what you are going to discuss, so have an agenda. You can expect that team members and/or stakeholders will disagree at some point and will need to work to resolve their differences, so have a plan for triaging issues as they come up (e.g. put them in "the parking lot" so they can be addressed at a follow-up meeting). You can assume that people on a conference call are less likely to be engaged in the conversation and may not be paying attention at all, so have an approach for keeping the meeting engaging (an agenda helps) and holding each member accountable. (I have found the "around the room" method of asking specific questions to each member of the group helpful.) While you may not know all of the risks or how to avoid them, you should have some idea of what to expect. Be proactive in both identifying potential risks and developing possible solutions for effective time management.

6. Do not be afraid to ask questions – If you have been reading carefully, you may have noticed that each step above involves a mix of starting with what you know and learning as you go. Asking questions is no different. In my opinion, asking questions is one of the best ways to learn. It can show your team that you are making an effort to understand, and it can encourage others to ask and learn along with you. And as you ask (and listen and absorb the answers), you will grow in your asking. You will learn what questions to ask, whom to ask, and how to ask them. But you cannot learn if you are not asking. So ask away.

It's that simple! Start with what you know, and learn as you go! You probably know more than you give yourself credit for (although it may help to read blogs and articles and talk to your manager, mentor, or advisor). The important part is to start, to learn, and to keep going!