A Correlation

https://www.projectsmart.co.uk/keeping-tabs-on-projects.php

After completing my project management course at DePaul, the dots began to connect. The course has created a well round view of what goes into managing a project. The various tools, skills, and resources necessary to being a successful project manager. From estimating project cost and timelines, managing risk, to scheduling resources and cost, this course has taken me from an unclear idea of what project management is to a more refine idea of what a project manager does. The experiences I have encountered while working on our group project and the individual interview helped immensely define and illustrate the responsibilities of a project manager.

Furthermore, after reading the article “Keeping Tabs on Projects,” I have drawn similarities to my experience in the group project and to Kevin Wood’s experiences (the person I interviewed) as a project manager. Projects have a lot of moving parts as I have discovered in our teams experience. I would imagine at a company, one might even have multiple projects going on simultaneously. To successfully run a project, being able to keep tabs on every aspect of the project is vital. In my experience with my group we did this extensively through emails, meetings, formal reports for class, and informal conversations over the phone/texting. In the interview with Kevin, this was one of the topics we discussed in-depth. He mentioned some days he only spends reporting on various aspects of his project, whether its to his supervisor or his client.

“Keeping Tabs on Projects” discusses implementing a systematic way to keep tabs on everything without having to dig through emails and notepads. My group did this by creating a workflow chart. Its important to keep upper management informed along the way. By doing so, it can make the project easier with them as far as support and proper resource implementation.

In the article it discusses that in the beginning of the project its important to identify the roles every player will be responsible for. By identifying those individuals and what roles they each will play, the project manager will understand what information they will need for further execution. By keeping tabs on the individual deliverables, it allows the project manager and the group to help identify problems and potential roadblocks. In my groups experience, I was responsible for finding potential locations for our event. By getting the appropriate information to my group early on, we were able to make a sound decision on where our event would best benefit our cause.

 

Product manager vs. project manager: who is what, and why is each important

During our first 2 weeks of class, I have been assessing how my company handles project management, and where to find our PMO group. Regrettably, our company does not have a dedicated group that handles all our company’s projects. This led myself to re-assess how our company operates under its current organization, which based on our customer needs, Hotwire serves to be a fun, spontaneous travel site that attracts advantageous travel geeks. Our goal is to develop a great travel experience, and this hinges on product development. Product development has similarities with project management, developing a scope, executing on the deliverables, quality control, and completion. So I searched what was the main difference between these organizational groups, and found an article that describes how a product manager sees the difference (listed at the end of this post).

The article discuss the differences between product and project management. Product management is “focused on the end-to-end life cycle of an identified value-proposition”, and I see this group supporting an on-going goal. Ultimately, product managers serve the purpose of delivering products to its customers. The article breaks down project management simply as having a “narrower scope, delivering an outcome defined by someone else”, and which gives the impression that project managers have a purpose based on around strategic decision makers.  The article gave me the impression that product managers are miss understood, and should have a clearer view of their role in the organization.

So, I as reflect on the author’s view of product management and project management, I see the similarities with my own firm, but in the reverse. Project managers have an unclear role in our organization because of how our company organizes it’s priorities around product development. As a Hotel Account Manager, I work closely with our product teams, who oversee different functionalities on our site. These functionalities include product placement, special tagging, promotion features, and specialized amenities (like free parking or complimentary breakfast). In addition to these different product types, our product teams are organized into different categories like mobile, supplier tools, content, pricing and email marketing.

When it comes to our company’s project managers, they are involved in new product releases, technology conversions, and having ownership over key initiatives. Some of these initiatives are related to our companies score card that track different strategy goals, and our project managers are either key senior managers or proven contributors assigned to a special project. To give further insight, our team assigned one of Regional Managers a project to oversee a conversion of a sister travel site. Our Regional Manager led the project for 3 months, and after completing the project, continued to manage his region. Ultimately, I believe our company is set up for success, but I wonder how we could be a better organization with a dedicated PMO team.

Does anyone see a similar project management set up with their organization?

http://www.jtpedersen.net/2013/01/25/whats-the-difference-project-manager-vs-product-manager/

 

Project Management: The Good, The Bad and The Ugly

Do you sometimes see your project manager as just the “jerk in charge?”

The course material has resonated with me in that I am able to identify the need for project management in certain areas of my workplace where this is lacking; such as developing systems for interdepartmental communication and talent acquisition and retention. But, can this be done in the project/program setting with definitive time lines, goals, budget, planning and execution? I think so!

To examine this further, let’s review two examples of projects that I’ve taken part of during my career in the Association Management Field which starkly contrast with each other. One, the successful implementation of a global acquisition strategy for a stand alone association. The other, an abysmally failed attempted to reorganize the digital file structure of an Association Management Firm representing 40 clients and employing almost 250 people.

The latter project, in my opinion, was the attempt of an executive assistant to prove her worth to the company. Beginning with the notion that a one size fits all file structure would be suitable for different account teams representing vastly different clients from many different industries was mistake number one. The project managers did not take the time to properly assess what the organization’s true needs and wants were and simply operated under assumptions. They may have been doing this to avoid scope creep, which often happens in the Association Management Firm setting because there are so many different agendas that come to the table. However, in this instance where the project largely affected day to day operations, failure to involve the entire organization in the planning process lead to a great amount of internal imbalance.

The next mistake was formulating an unreasonable timeline, which included several hours of pointless meetings and then full days, or even weeks, where entire account teams were taken away from their work and forced to moved files around within the network to comply with the new uniform structure. I was personally affected by this as my account team had a system in place for invoicing which relied heavily on file paths – all of which would have to be changed due to the relocation and none of which was considered or anticipated by the project manager. This was an absolute waste of human capital and client’s suffered because of it.

The successful project was one that was carefully cultivated over a two year period by a project manager with a strategic and forward thinking mindset. The Global Development Department at my current company put together an ROI tool which will allow them to assess how to approach various different markets. Each department had a seat at the table and everyone’s role in the process was considered. While implementation is just now beginning, there is great excitement! A good project manager should be able to generate positive feelings about the project – as opposed to the previous example which generated a lot of groaning and eye rolling. I hope to be able to partake in and lead more successful projects like this one in the future.

 

Are you an unofficial project manager?

I have just the blog for you! The article I found includes six project management skills taught by FranklinCovey (“7 Habits of Highly Effective People”).  The article is dated, but hopefully you will find the skills still very relevant. I have provided the six skills (paraphrased) and included my thoughts.

1. Implement foundational behaviors to master informal authority. Respect all stakeholders that may affect the outcome of the project, and you will receive the best work. Showing you value the stakeholders helps you inspire following, without formally establishing authority.

  • Thoughts:  One easy way to develop this skill is to lead a meeting.  This informal leadership is accomplished through organizing the discussion, seeking feedback, and keeping the meeting focused. If there is someone else who wants to lead, you always have the final say to end with a summary and a list of next steps.

2. Initiate. Identify and interview a project’s stakeholders. It is best to avoid the question “Why didn’t you check with me?” when verifying stakeholders. Planning ahead ensures you do not make the wrong assumptions about key people, and helps to set expectations and results.

  • Thoughts:  This skill takes time because you have to learn who to seek for information. From my experience, you may not know a key stakeholder at the beginning of a project. Based on issues raised, you may have to reach out to someone you had not previously worked with. It has been effective to include that person in the middle of the project, and explain that a new issue may require their feedback.

3. Plan. Identify risks, and create a plan to manage them. It is strong wording, but the article mentions failure if you do not have a schedule, in writing.  Also, what is your number one risk?

  • Thoughts: I found this one to be the most straightforward. A great practice of risk is to ask “if I do nothing, will it get worse?”

4. Execute. Holding people accountable is the article’s main focus. The leader should not embarass anyone, but ensure support is given to complete a task.

  • Thoughts: This may prove most challenging to a project manager. What has worked for me is to ask questions like “what can I do to help?” and “where do you see the bottleneck?”

5. Monitor and control. The most important thing here is managing changes in scope. The Project Manager has to have that conversation if change occurs, and discuss results of a change in scope in dollar value or other measure.

  • Thoughts: I read about team projects from the blog and listened to 2 students in class as they shared what can happen with “project creep.”  Project creep is costly in time or resources, so it’s advantageous to stay focused.

6. Close. Review lessons, and recognize accomplishments.

  • Thoughts:  There is a sense of excitement to completion!  Celebration is necessary and also creates an environment to do it again!

I most identified with skill numbers 1, 3, and 5. What skills do you most identify with?

Reference:

http://www.chicagotribune.com/lifestyles/sc-fam-0219-lifeskill-project-management-20130219-story.html
http://pm.franklincovey.com

Free webinar:
http://pm.franklincovey.com/upcoming-events/webinar/

Misericordia in Motion – Team 5

Misericordia Logo

 

Project Description:

The goal of our project was to partner with Misericordia Heart of Mercy and provide donations and service to help bring awareness and further contribute to their cause. Our team participated in two service events for Misericordia as well as raised donations and awareness through social media and online outlets. We hosted an event with a family-friendly movie for residents and the general public which also included other activities such as yoga, dancing, face-painting and a silent auction to generate monetary donations to Misericordia and also interact with and engage the community. Four of our team members also volunteered at the Greenhouse Inn for Sunday brunch at Misericordia’s campus restaurant. Our group maximized online donations through the implementation of social media outlets such as Facebook, Twitter, Instagram, and LinkedIn. This social media exposure and personal networks brought significant online donations through our FirstGiving.com page as well as provided valuable awareness to the work done at Misericordia.

DSC_0636DSC_0726

 

 

 

 

 

 

Charity Information:

Misericordia is a Chicago-based not-for-profit corporation serving persons with developmental disabilities.  Misericordia serves more than 600 people through a wide variety of programs.  The Mission Statement of Misericordia is to “support individuals with developmental disabilities in maximizing their level of independence and self-determination within an environment that fosters spirituality, dignity, respect and enhancement of quality of life. We promote development of natural family and community support, community awareness, education and advocacy.”  Misericordia offers a continuum of care based on the needs of the individual.  They also offer peace of mind to the families of residents since they know their loved one is cared for in a way that will enhance their life.  Donations allow Misericordia to offer more than just room and board for residents and offer them exceptional programs, such as intervention by physical therapists, occupational therapists and speech therapists.

 

Success Metrics:

Goal #1: Generate $3,000.00 in revenueDSC_0718

Our group was able to produce $2,795.00 in revenue and we reached 93% of our intended goal.  This was amazing as approximately 70% of our revenue was generated entirely online through our personal/corporate networks and social media outreach. Through many in-kind donations and resources we were able to minimize expenses to $30 and the entire remaining balance will be donated to Misericordia.

Goal #2: Provide 48 hours of service

Our group was able to produce 58 hours of service to Misericordia through two service events. The first service event had a family-friendly movie for residents and the general public which also included other activities such as yoga, dancing, face-painting and a silent auction. At this event we had approximately 60 attendants including 45 Misericordia residents. Four of our team members also volunteered at the Greenhouse Inn for Sunday brunch at Misericordia’s campus restaurant.

DSC_0744DSC_0783

Goal #3: Have a social media reach through 4,000 impressions

Our group was able to produce over 175,000 impressions! Our original objective was to produce 750 likes and 3,000 reach on Facebook, 25 retweets on Twitter, 25 hearts on Instagram, and 10 snaps on Snapchat or approximately 4,000 impressions. By combining all of our social media exposure through the listed social media outlets, including LinkedIn, our group was able to far exceed our original goal by producing over 175,000 impressions. Each impression provides awareness and recognition for the valuable work Misericordia does.

    DSC_0622

Advice for Future Teams:

  1. Defining individual responsibilities and workflows is key. By having individual ownership, everyone was held accountable and felt that their contributions were part of a collective goal.
  2. Decide on a goal or mission and stick to it. It is imperative to have a clear and attainable scope for your project. Scope creep can be easily overlooked and before you know it you have a completely different project.
  3. Have an online presence. With the various conflicts people have whether it be family, other classes, work, etc it is very difficult to get everyone in one physical location. Our group utilized Google Docs and Google Hangouts to make sure that more people are able to participate no matter where. In addition, our group took advantage of online donations as part of our online presence.

Lessons Learned:

  1. Having a team mission is critical. By understanding what it is your team wants to accomplish makes other decisions much easier. For example, when venue conflicts arose our team knew that the involvement and engagement of Misericordia residents was more important and this ultimately prevented us from changing venues.
  2. Continue to monitor risk and make any updates for new risks that may occur. With so many variables in the field project it is important to have contingency plans. Having an effective risk management plan allows for your team to be proactive in dealing with future issues and have a proper response to overcome the issue.
  3. Utilize an effective communication strategy. There are many applications groups can use to make communication easier such as the app Slack. Setting some rules of communication and having a proper way of communicating allows for the group to work together more effectively. In addition, this will help eliminate some redundancies in communication such as email overload.

Trek Bicycle: How PM software can change an entire company

Trek Bicycle Corporation is a major multinational bicycle manufacture based in Waterloo, Wisconsin. Up until recently, different divisions used varying software programs and communication styles to perform its project management. This lead to constant delays in getting new products to market as well as missed sales due to stocking out at key times. When Kris Lamp took on the newly created position of program manager, she initiated a search for a unified project management software suite. There was a clear organizational need for a product that would allow for seamless communication amongst divisions around the globe.

The company chose AtTask (which in early 2015 rebranded as Workfront) as their Enterprise PMIS solution. Under Lamp’s guidance, the implementation was kept simple. They opted for a software-as-a-service (SaaS) model, which transferred the support risks onto the vendor. Also, the company opted for minimal customization to the PMIS and chose to implement the rollout to one group at a time. This slow start allowed for the project team to work out any issues as they came up and before larger scale implementations. This mitigated the risk of project failure by starting simple and allowing time in the schedule for early rework.

Trek and the PMIS project management team heavily relied on management buy-in to help with employee adoption of the new system. Because the PMIS was eventually rolled out company-wide in many different countries, the project management team utilized local managers to encourage and/or mandate employees to adopt the new PMIS. In return, the PMIS project team kept manager notified of changes far in advance and conveyed why and how the changes would happen. The overall consensus from employees was that the PMIS not only helped with daily work, but also helped them feel more connected with the company’s work.

The PMIS implementation was almost immediately considered a success. End-user buy-in was high and due to their slow but steady implementation, they were able to begin to introduce customization. On-time delivery rates improved 20 percent, which directly benefited the bottom line.   A few years after implementation, 800 projects were being managed using the PMIS. These projects were being managed much more smoothly than far fewer projects the company had prior to the implementation.

Lamp credits the PMIS’s implementation success to decisions made early on by the project team. Choosing a vendor that had an off-the-shelf product that fit most of their needs and was able to provide support alleviated much of the early risk of failure. By using a slow and careful implementation, group by group, change requests were minimal and easy to handle. Most importantly, the team was sure to provide ample advanced communication to managers about the software. This allowed managers to educate employees on why the change was happening and why it was so important to the company. Overall, the PMIS took Trek’s project management from an ineffective and redundant process that frequently went over schedule and budget, to a transparent and seamless linking of divisions.

Does your company utilize a PM software suite?  If so, which product do they use and what is your opinion of it?

Overby, S. (2014) Trek Bicycle Rides Project Management Tool to Efficiency. CIO Magazine, retrieved 7/23/15 from http://www.cio.com/article/2377427/project-management/trek-bicycle-rides-project-management-tool-to-efficiency.html.

The Art and Science of IT Project Planning

Software projects face a unique set of challenges when it comes to scope estimating and this is especially true for new software developments. Research has found that poor cost and schedule estimates are much more detrimental to software projects than any other problem. Typically, estimates are based on historical project information and/or expert opinion, which can be more of an art than a science. The author, William Roetzheim, suggests a more systematic approach to planning estimates for new software projects using research-based techniques.

Based on his experience with software projects, Roetzheim suggests companies take an approach similar to that found in the PMBOK when it comes to life cycle cost estimating accuracies. Initial estimations should be within +/- 50% of the actual cost and the budget should continue to be refined as the project’s requirements are more fully understood.

Screen Shot 2015-08-02 at 3.47.37 PM

The first step to estimate scope is to determine metric used as a measure of scope. In software there are numerous options, but the most common is the number of source lines of code (SLOC), which is the number lines of code written by humans and is usually given as thousands of SLOC (KSLOC).

To determine the number SLOC, you can use one of two options: the direct estimating approach and the function points (FPs) with backfiring approach. Using the direct estimating approach, you break the project down into modules and use multiple expert opinions to estimate the number SLOC’s per module. This is called a Program Evaluating and Reviewing Technique (PERT) calculation and is done by obtaining optimistic, pessimistic, and most likely values. The most likely value is weighted times 4 and the mean and standard deviation are calculated and used to create an estimate with a high level of accuracy.

The FPs with backfiring approach uses the estimate of the number of logical internal tables and external inputs, outputs, interface files, and queries to estimate the number of ways the program must interact with the users. Then you multiply the raw data by its FP conversation factor to fund the number of FPs.

Screen Shot 2015-08-02 at 4.43.29 PM

Then using backfiring you convert the FPs to SLOC using the function point for the applicable language.

Screen Shot 2015-08-02 at 4.43.43 PM

Once you have estimated the number of KSLOC, you take that number and multiply it by the effort required per KSLOC to find the estimate for the project. Researchers have come up with estimates for the effort required per KSLOC based upon different project types. For smaller projects, you would multiply the number of KSLOC by the productivity factor of the applicable project time to find the number of person-months the project requires.

Screen Shot 2015-08-02 at 4.11.04 PM

Since research has found that large projects tend to be less productive due to increased time spent communicating and coordinating, you must apply a penalty factor to the above calculation for larger projects. The calculation for the larger project would then = Productivity Factor * KSLOC^Penalty Factor.

Screen Shot 2015-08-02 at 4.11.15 PM

The author argues that the calculation above will deliver a reliable person-months estimate feeds into the project’s schedule and budget and that it should continue to be managed as the project moves forward in its lifecycle.

While the author’s presents his methods for estimating scope for a software project, he does make any recommendations on how to utilize them. If your company conducts software projects, does it use SLOC when estimating? Is there a specific process used to calculate time requirements and how does it compare to the process suggested by the author?

Roetzheim, W. (2005) Estimating and Managing Project Scope for New Development. Journal of Defense Software Engineering, 4-7.

http://static1.1.sqspcdn.com/static/f/702523/9277557/1288927629910/200504-Roetzheim.pdf?token=Iy0EhkuVC%2Fp4nH9ybNkoKNjsICw%3D

So this is what Deja vu feels like…

About a year ago I was working my first big job on a large web project. I had to teach myself pretty much everything along the way. My supervisor asked me many many times when (approximately) I would finish each part of the project. I never really understood what all the fuss was about regarding timelines. I never knew what to say. On the inside I always thought that I would just get it done when I got it done. I was not able to predict efficiently until the very end of activities how long they would take because everything was relatively new to me. Now in hindsight I see how helpful these planning concepts and skills would have been in planning and changing the project according to time constraints. Learning planning techniques in class such as identifying activities, mapping out precedence, estimating time and identifying critical activities/paths is very new for me but finally brings all those questions I was being asked into perspective. I knew that having time estimates was important and necessary to plan but I never realized how important and complex planning could be. I now plan to take a more proactive approach and will do my best to give time estimates when possible in future projects.

I am glad to say that as I am learning how to plan in class I am applying what I am learning in another classroom. In another class I am currently in we have to plan, design and build a web application in 10 weeks. This means that time is valuable and we need to balance it out with the other key project metric triangle components to make sure performance and cost (our personal time in this case) are within reason. In this project we have had to develop a GAANT chart and plan out some of the most meticulous details of the project weeks ahead of even starting to build it. In addition, we had to plan out how long activities would take. When the planning requirements were brought up in the class I was one of the only students in the group familiar with the basic terms due to MGT 301. I have been able to help the team and manage our time so that we do not get behind in our project. We have identified activities that can be crashed (by investing more time in the week and putting our more experienced group members on specific tasks) as well as identifying activities that could be run concurrently (done at the same time) so that we can get more done in the same amount of time by splitting our group into mini groups.

Questions:

–          Have any of you had the above issues at a new job or on a unique project?

–          Have any of you seen the lessons and concepts we are learning in class come up in a current or past class?

–          How did these concepts help you to do better or contribute in that class?

–          Have you applied these concepts to a class or work project?

Get in the Shower if it All Goes Wrong

The worst think about working on a project, especially when you’re the manager, is when you can feel it failing. Both you and you team know you are losing your grasp on it and you feel powerless to stop it. Whether it be in a school project, or at work most of us know that feeling.  This is a hard pill to swallow because it means accepting that there is a problem with the path that has been taken.

So how do you get past this? How do you revive a team like that? Should you scrap the project all together losing all the time, energy, and resources put into it? Or should you power through with a bad plan just so you can finish? Maybe you could complain loudly, but ultimately do nothing to change the situation. I’ll admit I have occasionally been that person. It’s not something I’m proud of.

While these steps might be easy to do they aren’t always the best course of action. Here are some simple tips to get your project back on track:

Identify the problem

To fix the problem you have to know the problem. Take a step back and evaluate the situation, you need to understand exactly what went wrong and when. Now you have a starting point to build upon.

Get in the shower

Literally or figuratively clean yourself off! Rid yourself of the bad feelings you previously had towards the project. While this tip might seem unessential, it is actually quite important. If you refuse to let go of your past failures with the project it will make moving forward virtually impossible, it can hinder your ability to come to the table with an open mind ready for a fresh start.

Talk to your team

Communication is key. To get your team back on track everyone needs to be on board and working towards the same goal. This is not a time to try and place blame. Make sure everyone knows their role and how it contributes to the bigger picture. If possible, encourage an open line of communication to eliminate a breakdown in the project due to a breakdown in communication.

Reboot

Learn from your mistakes and refocus yourself. Based on your identification of the problem create a new plan that solves it. “Issue a revised scope statement, obtain the funding, reset the schedule and obtain appropriate approvals. You have been given a new lease on your project” (Cutting).

This list is by no means comprehensive and these are only beginning steps to fix a bigger problem. But start here and you’ll be on the right track to saving your project.

How could you expand on this list? What tips do you have for saving a project? What doesn’t work? How do you know when a project is no longer salvageable?

Sources:

http://www.projectsmart.co.uk/how-to-really-fix-a-failing-project.php

http://fortune.com/2013/11/22/4-steps-to-turning-around-a-troubled-project/

Starting at Red

In class we talked about how project managers often use the red/amber/green method to signify if a project is running on track.  My company uses the thius same approach to track project work as well as many of our monthly KPI’s.

Most if not all projects typically start with a green indicator and will remain that way as long as the project completes on-time.  I read in interesting article called “Starting at Red” that suggests all projects should start with the color red.  The reasons cited in the article are as follows:

  1. When a project begins, the team is as far from delivering anything as it will ever be. Sounds pretty much like a “Red” scenario to me. What if the project remained at “Red” until the PM could justify downgrading it to “Amber” – based on progress achieved, and then eventually (hopefully) “Green”?
  2. Green at the beginning doesn’t work because we have no idea if we’re going to achieve our goals so saying the project is “Green” really means “we haven’t yet found a reason why we won’t deliver”.
  3. If a project starts at “Green” and remains “Green” all the way through, at what point does it go from being “we haven’t yet found a reason why we won’t deliver” to “we will definitely deliver”? At some point it will have changed, but this is not recorded by a change of project status.  Seems like an important distinction to make.
  4. “Green” is a problem because reality doesn’t work like a textbook. It is usually very hard for the PM to change the project’s status.
  5. Starting at “Red”, there is no need to worry because a “Red” status is the norm. This clarifies that “Green” only means “we will deliver”, and no project can go to “Green” until it is clear that the progress made justifies the change of status.
  6. The PM will naturally be keen to find reasons to change the status to “Amber” and then “Green”, but this will require delivering good news, and justify the change – which is much easier than delivering the bad news required to go from “Green” to “Amber” to “Red”.

The article summarizes by saying that starting at “Red” makes it easier to focus the team on the critical activities required to go to “Green”. Everything else is secondary. This is the kind of project environment that is usually only created when there is a serious problem. Why wait until then? Start with the attitude that the project is going to fail unless you take immediate action – because it is!

The challenge posed at the end of the article is for all PM’s to try this on their next project as see how it works.  Would you be willing to give it a try?

http://www.projecttimes.com/articles/starting-at-red.html