Trials & Tribulations of a Project Manager…

Now that we have the Project Plan clearly defined – let’s take a look at what composes a Project Schedule. This is something that is near and dear to my heart as I literally helped write the book on the Practice Standard – Scheduling for PMI. It’s also a key component in executing and controlling any project.

Simply stated, you could say that a project schedule is the formal document of completing several different processes. Another way of looking at a schedule is to say that it is comprised of several different components. At the very least you would want the following:

• WBS (Work Breakdown Structure)
• Time estimated for each work package
• Dependencies (example: work package b cannot start until work package a is completed or work package c and d can be done simultaneously)
• Resource Names (who is responsible for each work package)
• Start and Finish dates for each work package
• Lead & Lag times for each work package

With those six components you could create a project schedule using yellow post it notes. You may laugh, but I’ve actually done that to make a point.

Utilizing software such a MS Project, Project Server, Primavera or Niku Clarity, you can create a project schedule that will level resources, create budgets, help you determine EVM, create PERT charts, Gantt charts and host of other features that can either make a project managers life easy of very complicated depending on how the tool is configured and how well you understand the tool.

Another major component of project scheduling is understanding that your project schedule will change. This can irritate project sponsors no end. However, it is my job to communicate that in the beginning, we don’t know what we don’t know. When I create a schedule with the team in the early phases of the project, it is with the understanding that we are about 50% accurate. What I mean by this is that we might only have a scope document when creating the 1st iteration of the project schedule. Scope says we are creating a widget that is bigger than a bread box but smaller than a refrigerator. At 50%, a work package that we estimate to take two weeks, could in reality take 1 week or 3 weeks. Once the team has nailed requirements though, that schedule is pretty darn accurate. We know exactly what we are building. By this time, we’ve also completed our risk management plan and assessed the risk associated with this project. Contingencies are planned for. Now that schedule is said to be 80-95% (depending on the maturity of the team) accurate. This is your baseline. It’s important to have a baseline schedule and budget when utilizing EVM (Earned Value Management).

I cannot tell you how many people have come up to me in person or on pm boards letting me know that they absolutely hate MS Project. In my experience, the reason for the vast majority of frustration with Project is not understanding the processes and components to what makes a schedule. You don’t just make a list and bam, you are done. MS Project is definately not intuitive though each version has gotten better. Had MS 2007 been around when I was in France, my life would have been awesome

All that being said, let us delve further into the components of a schedule. The very first being a Work Breakdown Structure. Tune in to the next post…

Okay, I have to admit – this is one of my largest pet peeves. There is a HUGE difference between a project plan and a project schedule!!! Inevitably though, most people use the terms interchangeably. I think the biggest cause is Microsoft and MS Project but that is a rant for another day. Below are the definitions and differences between the two. You need both to successfully manage a project.

PMI defines a project plan as “…a formal, approved document used to guide both project execution and project control.” A plan defines how you are going to manage risk, issues, change, communication, resources (human and non human), testing, turn over, really anything that helps execution and control but has nothing to do with specific dates. Think of it as a document or series of documents that state how, why and what will be done and then who will do it.

A project schedule is whole different animal. It states what work packages are being scheduled, who is responsible for which work packages, dependencies between work packages, resources needed for work packages, start and finish dates. A project schedule does not tell you how everything will be done. It does tell you when things will be done and who is responsible for each item.

WHY ARE PLANS IMPORTANT?

Plans are important because it lets the team know up front how things will be managed. A great example of this would be a Change Management Plan. What is a Change Management Plan you ask? Basically, it is a plan for how to manage any changes to the project whether that be requirements (the plan would only go into effect for requirements after the requirements document is signed) or scope. It lets the team know what needs to happen when a change is requested. It allows the project team to plan for changes. In this way, you communicate to the entire team what those changes mean. This also allows the project sponsor(s) to see the impact of those changes.  For those of you that have worked on a project that was supposed to take just two months to complete and six months later, nothing is finished – you might like what a Change Management Plan does for you.

The Change Management Plan might contain the following:

• Diagram of the Change Process
• List of various roles that individuals play during the process and exactly what is required of each individual (approval, review, input, impact analysis, etc)
•  Narrative of the Change Process
• List of items that shall be considered for Impact Analysis (how could this change impact scope, timeline, resources and budget)
• Documentation that needs to be completed

Many projects that do not have an agreed to Change Management Plan experience something called “scope creep”. A project sponsor or team member might come up with different ideas to add to the project. They may be really awesome ideas that come about as you are fleshing things out. A developer might look at the idea and think, oh – this will only add about 8 hours to the programming aspect, no big deal. So, the team agrees – yes, great idea lets do it! Awesome, fantastic, incredible!!! Then someone else has another really great idea to add on and then another. All small things when looked at individually. The only thing is that before you know it, your budget it overrun, your schedule is out the window, your project has gone to hell in a hand basket and everyone is wondering why. If you have a plan for what to do, life is much more productive.

Up next – what should be included into a Project Schedule and why do most project managers not use them past the planning phase????

It’s funny. As I was first starting this blog and making my initial posts, I realized something for the first time in a long time. In the beginning, I was constantly thirsty for knowledge. I picked the brains of the more experienced project managers around me, I read books on the subject (you can check out my amazon list for a reading list), took LOTS of classes, went online to places like gantthead.com, went to seminars, attended webinars, you name it and I found it. What I realized is that around three years ago, I stopped taking classes. It was almost as if I thought I knew everything and got so wrapped up in my projects and the day to day of project  management that I forgot to think strategically about my professional development.

So,  I’ve decided on the following classes and certifications:

• MS Certified Application Specialist (MCAS)
• MS Certifed IT Professional (MCITP)
• Masters Certificate in Program Management from ESI and George Washington University (includes the following classes)
  • Program Management
  • High Impact Communication
  • Taking Charge of Organizational Change
  • Administration of Commercial Contracts
  • CPIC & the Exhibit 300

I’m pretty excited about learning new things and getting certified in things I already know!

Assuming your project has been given the green light by your PMO or upper management (meaning that management has an idea or even a SWAG of what it is that shall be accomplished, how much it may cost and what types of resources may be needed), the very first thing you want to document is your scope document. This could very well be a further fleshing out of whatever document was used for approval processes or a completely new document. I’ll talk about the project approval process and portfolio management in another later post.

A scope document consists of several things and may vary from company to company. However, the main function of a scope document is to capture what is and is not considered in scope. Think of it as a contract between your project sponsor(s) and the project manager. This insures a clear understanding of what is expected, at a high level, of the project team. It also insures that the management team involved all have the same vision of what the project will accomplish. Having this scope document can save everyone massive headaches down the road. In this way, there is no one saying, “well, i thought the project was going to do X” and someone else saying, “no, this project is going to do Z”. It may take several iterations of review before everything is captured.  For example, if you were looking for recommendations for a new software that manages your widget shipping process, you might have a column listed “in scope” and under that you might find items like;

·      Vendor Recommendation Document with matrix

·      New Test Environment

·      User Acceptance Testing Plan

You would then have a column labeled “out of scope” with some of the following items;

·      Implementation Plan

·      Signed Contract with Vendor

·      Production Implementation

·      Maintenance Plan to include future budgeting for five years

The idea behind a scope document is to have something written down that clearly communicates what the team understands to be required of them from a 40,000 foot level. This can be shared throughout the company so all understand what the project is doing.

Additional items you might find within a scope document are;

·      Key Success Factors & Criteria for Evaluation - how will we know if the project is a success? This could mean many different things to many different people. The main objective of this item is to clearly define WHAT the success factors will be and HOW they will be measured. So you would actually have a key success factor listed followed by the criteria used for evaluation. It might look like the following:

o     Selection of Software Package \ Vendor Recommendation document clearly outlining the process of how the selection was made

o     Within Budget \ Budget deviation of no more than 15% of baselined schedule costs

·      Major Milestones – what can senior management use to understand progress at a high level? They may include some of the following:

o     Scope Document Signed

o     Project Schedule Baselined

o     Requirements Document Signed

o     Physical Design Completed

o     Test environment Completed

o     User Testing Completed

o     Formal Recommendation Completed

o     Project Close Out Completed

·      Assumptions – what are the assumptions being made at this point in the process concerning this project. They may include some of the following:

o     The short list of vendors supplied by X is sufficient

o     All vendors are in compliance with Y

o     Anticipated maximum widget capacity is Z

o     This is a purchase, not build decision

o     No customization of software is to be done

·      Constraints – what restrictions are we working this project with? This could be anything related to design, other projects, budget, etc. They may include some of the following:

o     Vendor Recommendation must be completed by 01.01.10

o     Vendor Recommendation must be Oracle 9i compatible

o     No new hires for this project – must use existing resources

o     No new hardware is to be purchased – must use existing hardware

o     Software has not been selected to manage the widget creation process. Therefore we will not be able to test compatibility.

·      Related Projects – are there any other projects currently going on or about to kick off that are related to this one and could have an impact?

o     Software selection of widget creation process

o     Infrastructure redesign and upgrade

·      Risk Factors – what are the current high level risk factors that we are aware of today? What might be their impact?

o     There are dozens of software packages to select from. We are using a short list provided by our consultants which may cause us to overlook a better solution

o     The widget creation process software will not be completed until 01.10.11 – therefore, we will not be able to test compatibility of the two software.

o     The infrastructure redesign and upgrade project is in process and if there are changes, we may have to test the software again with new environment which increases time and cost.

·      Sign Off – Who must be included in approval of this project?

You might also include a brief description of the project and\or a history of how the project came to be. Others might also include a high level timeline from the milestone perspective.

One of my experiences has been working for a subsidiary of a company where the parent company required my hiring. That experience taught me a LOT!!!!

Number one was that I didn’t ask the right questions during the interview!!!! Talk about a unique situation. Only after starting did I find out that the true objective was to turn a program around that had been derailed by my new boss. AKWARD!!! Seeing as that boss wasn’t fired but actually promoted to VP of Project Management, I had to tread lightly and carefully. It was one of my most challenging, frustrating and yet highly rewarding times in my career.

Frustrating in that the upper management of the subsidiary refused to admit that the old way of doing things had not worked. This despite the fact that the program they worked on with the parent company was six months behind and there were continued conflicting opinions on what was and was not in scope….

Challenging in that I was working in an environment where there had been no formal project management before…. at all. We were completely starting from scratch. Think about working somewhere that you have to introduce an entire vocabulary to the team!!!

Rewarding because, as I introduced concepts and theories and activities of project management, the majority of the team members understood and saw the huge benefits to formally managing projects. It made their lives SO much easier.

So what exactly did I do while working there? Read on as I introduce the various methodologies of a project management professional.

Upon moving out to California, I found a contract position that turned into a permanent full time position. One of the main reasons I accepted the position was because of the hiring manager – Bill Titov. He was an absolutely amazing boss. I was really annoyed that a few months after signing on permanently, he was transferred to another area of the company.

I digress though. OOMC was a young growing company and reminded me a bit of Wilshire. I learned a lot while working there and had a true chance to stretch my project manager legs. While working at OOMC, I was able to complete my course work and received a Masters Certificate from George Washington in IT Project Management. In addition, I also earned my PMP designation from PMI and volunteered on the core project team that wrote the practice standard for scheduling.

I loved taking all the classes I did and learning the theories behind risk management, systems integration, scheduling & cost control, earned value management, contract management, leadership, software testing and of course analysis. I especially loved being in the classes surrounded by people with different experiences and perspectives. Similar to my experience as a consultant, I was exposed to many variations of doing things. My classmates were in Fortune 500 companies, State & Federal Government, small start ups and the DoD. Outside of class, we were able to have frank discussions about the projects we were each working on and the challenges we faced.

Once I completed my course work and received my PMP designation, I volunteered on the core project team at PMI to create the Practice Standard for Scheduling. That was a really amazing experience. There were nine of us on the core team and I was in awe of the professional backgrounds of my team mates. Some had been project managers for over 30 years and instrumental in the creation of PMI. One of the pm’s worked on the Big Dig in Boston and hearing her tales behind managing that program was awesome! I loved being a sponge and soaking all the knowledge up. At the same time, I couldn’t believe I was picked to be on the team. It was really awesome to realize that I did have knowledge to contribute. Especially since I had just finished my coursework. I had studied hard and knew the theories behind Project Management.

I was quick to realize though that what I was taught at school in theory, doesn’t always work in the real world! While working at OOMC, we went through three iterations of implementing a PMO. Talk about a learning experience… It was fun and accelerating and tiring and annoying all at the same time. There were projects involving securitization, pricing, LOS, data warehousing, compliance, reporting, process re engineering, you name it. It also gave me a chance to use some of the knowledge I’d gained in France when it came to managing multi located team members. Several of the projects I managed utilized off shore resources. Not only did I have to deal with cultural differences and time zones but also contract issues. It was fun and challenging.

One of the biggest lessons I learned was that project management is not a science. You can educate yourself on all the theories and methodologies you want but unless you know which pm tools to implement and when, you will never successfully deliver projects. A good project manager knows when to apply science and when to use art.

The other point that was really driven home was that if you aren’t careful, you can get stuck in paralysis analysis. Never a good thing. It was here that I was first introduced to JAD. It reminded me a lot of my early days at Pace and XP.

All the different methodologies and PMO implementations further reiterated to me that one size does not fit all and trying to force an IT department to follow one methodology for all projects is not a good idea.

Once I got back to the States, I knew that I wanted to learn more about Project Management and that it was the career track I wanted to stay on. However, I was considered the subject matter expert where I was and there were no mentors available. I started looking for a position elsewhere and one of the companies that I liked the most was CC Pace in Fairfax, VA.

Working at Pace was my first introduction into formal project management. The Managing Consultants and Directors there were top notch. Susan Woodcock was instrumental in helping me understand formal project management as well guiding me to see that there are many methodologies for the SDLC and no single method is a one size fits all.

My requirements documentation improved significantly and on top of the consultant boot camp that Pace offered, I also started taking classes in Project Management through ESI and George Washington University. Being able to work at a variety of clients while at Pace introduced me to new industries and new ways of doing things.

It was also while working at Pace that I was introduced to XP – also known as Extreme Programming. It was similar in some ways to what I had done working side by side with developers back at Wilshire but in a much better organized, disciplined way. It was through my first introduction to XP that I also learned about Agile, SCRUM and OOD. I was absolutely enthralled at how many theories and methodologies there were when it came to SDLC and I couldn’t soak it all up fast enough. I read voraciously and was able to apply what I learned while working on various projects for numerous clients.

In addition, my classes through ESI were teaching me the theory behind Project Management. I loved learning that there was a logical way to manage risk, scope creep and issues. I joined PMI and met Project Managers that had 20 and 30 years of experience. Listening to their stories from the trenches was awesome!

Working as a consultant exposes you to several different companies and ways of doing things and I could see what worked and didn’t work. Especially when it came to PMOs. Also when it comes to software selection. It never ceased to amaze me that companies would literally spend millions of dollars in hiring consultants to select software applications for them but decide to go with a different application than the one recommended. A year later, they would rehire us because the application they selected wasn’t working for them and we would then come in to either customize or implement the original application. The entire process also reminded me managing IT projects is not just about the technology. It’s about selecting the right methodologies and communicating with people and managing expectations and taking into consideration everything that impact your project or portfolio of projects. Communication, communication, communication!

I would have liked to stay with Pace for a while longer but it was at this point that I met the man I married. His company relocated him to Southern California and so I completed my last project for Pace and headed west. Little did I know then what a roller coaster ride I was in for in both my personal and professional life.

While I was in Paris and London, I went to the school of hard knocks when it came to Project Management. There was lots of trial and error. It was an amazing experience though – baptism by fire. Project Management is a mix of science and art.

Like all industries – IT is no different; there is more to successfully managing projects than installing technology alone. I learned that France and the UK – while similar in some ways to the US, have significant cultural differences in business. While the US is very entrepreneurial and most of us are raised to believe that we can be anything, regardless of our background or education, the UK and France are not the same. Also – there are different priorities. In the US, we tend to work very long hours and make many sacrifices for our careers. While working at Wilshire in the US, it was not uncommon for the team to work 70+ hours a week. We did whatever it took to get the project done. While I was working in France, the mandated work week was 37.5 hours, it was virtually impossible to get fired, everyone was given at least six weeks of vacation each year and the theory behind success at work differed significantly compared to the US.

The French teams were definitely hard workers but once the 37.5 hours was done, that’s it. The first time I suggested we work on a Saturday to catch up to the project schedule, I felt like perhaps the guillotine was going to come out! The project schedule needed some serious revisions. At the same, I was dealing with my American managers who didn’t understand why the team wouldn’t work 70+ hours.

I also learned the challenges associated with having a team that was not co located. One had to account for not just cultural differences but also time zones. In Paris, we were nine hours ahead of the Portland office where our development team worked. I quickly learned to take turns on who was going to come in early or stay late for conference calls.

In addition, while I had worked with the developers in Portland before – I was in the same office building with them where it was easy to answer requirements questions. If a requirement wasn’t clearly defined on paper, it was no big deal to just pop over the wall and clarify. That doesn’t work when your team is separated by time zones and several thousand miles. This is where I learned the importance of clearly defined and documented requirements. It was here that I was introduced to the work of Suzanne Robertson and James Robertson. Mastering the Requirements Process was a fascinating read! I was amazed that entire books were dedicated to the process and I couldn’t read fast enough. I started meeting others in the profession and I couldn’t stop asking questions – I was so eager to learn.

Once you’ve clearly defined and documented your requirements, the entire SDLC becomes so much easier to manage. You can neatly tie your requirements to code and then testing and then release. It was awesome!!!

Another thing I learned on the France and UK project was managing expectations. A good PM needs to clearly manage not only the project sponsor(s) expectations but also the teams. It’s important to get buy in from all sides. I can not emphasize the value of a Project Charter and a Project Scope document enough. What’s in scope? What’s out of scope? How are we going to measure success? What is success? What is the estimated timeline? What are the milestones? What assumptions are being used to estimate the project? What are the constraints? Resources? Budget? Who or what departments or systems are going to be impacted? What are the major risk factors? What can the Project Sponsor(s) expect as far as accuracy of the scheduled budget, timeline, etc. You also need to understand how your project sponsor(s) like to communicate. It’s a relationship and like any other relationship it takes work and excellent communication skills.

I absolutely loved my time in France and the UK and would work overseas again in a heartbeat. I will forever be grateful for everything I was exposed to and learned while working on this program. It was really the beginning of my career as a project manager.

When I was growing up, I wanted to become the first female NFL player or a stockbroker. So, how did I become a Project Manager? Glad you asked! During my senior year of school, I completed an internship for what was then First Wisconsin National Bank in their Branch Adminsitration Group. It was a lot of fun. Working for that department meant I had the opportunity to interact with just about every other department at corporate headquarters; MIS, Marketing, Finance, HR, Loans, Personal Banking, Legal, etc. I loved having access to all the different departments and really being able to see the “guts” of what it took to run a bank with then 34 branches. It also meant I was able to meet and interact with all levels within the headquarters and be a “fly on the wall”.

I graduated that spring and my internship ended. I went on to work on my uncle’s dairy farm for the summer and came back to the city in the fall where I accepted a position as a Buyers Assistant for what was then P.A. Bergner’s in their women’s fragrance department. It was an amazing experience to see what it takes to not just bring a fragrance to market but everything that goes into the selection of what inventory to offer as well as the marketing plans it took to be successful in sales with 56 department stores spread throughout several states. As an Assistant, I was given the opportunity to attend new product launches and cocktail parties and exhibitions. It was a wild life and I wasn’t even legally permitted to drink.

The fast life was a bit too fast for me, especially for as young as I was back then. My mother saw how much I loved what I did but also the toll it was taking on me. I just wasn’t ready for the responsibility. She knew that I enjoyed being outside and working with my hands, she thought perhaps I’d be perfect as a carpenter.

So, off I went to learn how to be a carpenter. I passed the tests and found a company that was willing to apprentice a girl. I was one of the first women carpenters in the state of Wisconsin.  While entering my third year of apprenticeship, I was injured on the job by a 14 foot 2 x 4 flying through the air as we were setting trusses on 14,000 sq ft custom home.  It whacked me right in the knees and tore some cartiledge. I can still “float” my kneecap to this day.

Now, most people would have taken the workers comp and enjoyed their time off while recuperating. Not me though – I couldn’t stand to sit still. Around this time, a friend of mine from the bank told me about a receptionist position in the Real Estate department and thought perhaps I might be interested. So off I went to interview.

There were changes a foot in that department and the new hiring manager liked me so much that he offered me a position as a Junior Loan Processor instead. Thank you Jay Magulski!

That started me on the road into the Residential Mortgage industry where I stayed for several years. While working as a Processor, I learned that there were contractors that did the exact same thing I was doing but they got paid three times as much AND got to travel. That lead me to the contracting market where I worked for several different companies across the country as a Loan Processor, Underwriter and Due Diligence Specialist. Working in so many different environments was awesome. It was interesting to see how companies that were in the same industry, ran their companies so differently. I was a little sponge, soaking everything in. I’ve always had a curiousity as to how things work besides whatever I might have been tasked with. My favorite questions have always been how and why.

While working as a contractor at that point in time (two years) was great for me, the industry was going through a recession and competition was stiff for the contract positions.  I learned of a position opening at a small and upcoming company called Wilshire Financial in Portland, OR.

When I went on my first interview for Portfolio Anaylst, I wasn’t really sure that I was interested in the position. The job description seemed plain and unimaginitive. However, interviewing with Ken Kepp made me very interested in the company. It was young, vibrant and growing – there was room for me to thrive there. By the end of the interview, I knew I was hooked. As I flew back home from Portland, all I could think about was all the great things I could do at Wilshire and what amazing things I could learn.

Unfortunately, my second interview with the actual hiring manager, John McPhee, went horribly wrong. I usually ace both phone and in person interviews but everything that could go wrong with that interview did. The HR person got the time zones mixed up, the interview was on a cell phone (john’s) where we were disconnected three times, i said all the wrong things. It was a disaster! I remember hanging up the phone for the last time and being horribly sick with the knowledge of failure.

So imagine my surprise when I received a phone call with an offer!!! I’ll never know how Ken convinced John that I wasn’t the doofus I appeared on the phone but I’m forever greatful. One of the greatest things I learned from John McPhee was that being a good manager doesn’t mean that you have to have years of experience in the specific industry you are working in – what’s important is being able to think logically. I’ll never forgot when I learned that lesson. I had a problem with something I was working on and wasn’t sure what to do. I asked John about it and while he didn’t understand the technical parts of my problem – he was able to ask me logical questions that guided me to the solution. I had known what the solution was all along – I just needed to think it out logically. He was my boss and he didn’t understand what I was doing or what the issue was but he was able to guide me to the correct solution. Logic – it’s an awesome thing!

I received the offer on a Wednesday, packed up my things on Thursday and began the cross country drive Friday – arriving in Portland on Sunday and began my new position on Monday. Whew!!!

I loved working at Wilshire. It was an amazing incubator for so many of us. What had started as a leasing company was becoming a mortgage servicing company. The president had learned that you could buy portfolios of loans for pennies on the dollar. It was up to the loan counselors to turn customers around and convince them to pay up. Once they were performing, we sold bonds to industrial investors using the porfolios for collateral. In the beginning, I started out reconciling the portfolios to what we purchased. In addition to the financial reconciliation, this also involved data mapping and data transfers. That brought me into contact with the IT department and the developers. After completing several portfolio transfers, I began to develop a knowledge of the entire loan process from application to securtization. This was unique and I don’t think I would have learned it anywhere else except at a growing company where we all wore several hats. It also helped that I could easily communicate with the developers. The original LOS was actually a leasing application that gradually morphed into a LOS system. After two years, the application was so different and encompassed not just servicing but also foreclosures and bankruptcies. At the same time, the company grew beyond just the US and purchased a company in France as well as started a company in the UK.

I was set to officially transfer over into the acquisition and securitization department when I was asked if I was interested in moving to France and implementing and customizing the application for French & UK bankruptcy and foreclosure laws. I didn’t have to be asked twice!

Two weeks later I was living in Paris and that was where I learned that Project Management was an actual profession. Looking back now, it’s amazing to me that the projects in France and the UK were sucessful because by all rights it should have been a massive failure. I was only just learning about MS Project and had no idea even what the triple constraint was – though I would have gotten time correct. I soon realized that I needed to educate myself and it was at this time that I started reading on my own. I read every PM book and magazine I could get my hands on. I started meeting other Project Managers and was constantly picking their brains for ideas, theories and suggestions. Two years later, I was hooked on furthering my education and experience as a project manager.

What was it that intrigued me so about project management? I loved the concept of bringing organization to chaos. Those first projects I managed in Paris and London were chaotic. We were dealing not just with technology issues but also cultural issues and expectations across three countries. Three sets of ideas on what was supposed to happen, three sets of ideas on how it should happen and three sets of ideas on when it would all happen.  I didn’t know it then but it was my first introduction to portfolio management. How do you select which projects to invest time & money into? Everyone has their own gut instinct but the numbers don’t lie – it’s important to measure everything. I think what I like most about the organizational aspect of project management is that you analyze and bring clarification to your client. It makes sense.

And so – that is how this PM was born. Check back soon to read about me growing up and learning more about this amazing profession.