Tag Archive for Agile

Guestimating

Since the dawn of time, one of the questions most likely to strike fear into the heart of even a seasoned project manager is, “So how much is this project going to cost?” In fact, at Brightwork says there are hieroglyphs on the wall of the tomb of the great pharaoh Khufu, depicting the pharaoh asking Vizier Hermiunu, the pyrmid’s project manager, this very question about his burial pyramid and, a few walls down, a second depiction of the project manager being thrown into a nest of crocodiles in the Nile after the project overran its budget by a few thousand debens.

As evidence of how little project management progressed, Mr. Kreha relates how he sat in an questioning-techniques-in-training estimation meeting and watched an agile” project team assign “points” to “stories” in a vain attempt to estimate how much work they might get done in the next two weeks, aka the next sprint. And inevitably, a new team member would ask at some point, “so how many hours are there in a point?” Immediately, this agile novice is mocked mercilessly! “You don’t understand,” the scrum master and other developers say, “points aren’t convertible into hours or dollars. We use a Fibonacci sequence – you know, 1,2,3, 5, 8 and 13 – to estimate how much effort a story is. It has nothing to do with hours or money.”

And so we project managers are still left holding the bag for estimating projects, often early in a project’s lifecycle, and then being held accountable for them as if we were clairvoyant. What can be done?

Brightwork’s Kreha offers some hints on how to stay out of the croc pond. Start doing them, that might help:

  1. https://www.rmagreen.com/how-much-does-environmental-compliance-costSeparate ‘hard costs’ from softer costs when you’re estimating. Hard costs are things like license fees. Once you have a quote from a vendor (stall until you have one) you can be pretty confident that’s what the cost will be. Hourly labor, and time and material contracts in general, are obviously softer, since you’re funding time and not deliverables per se.
  2. For softer costs, use burn rates’ to look at low, likely, and high ranges for labor costs. For example, if you have a team of 10 with an average bill rate of $100/hour and they will be working on your project more or less full time for the next 5-6 months, you’re looking at $860k to $1M if I did the math right. Don’t get suckered into estimating hours without thinking about time, because things ALMOST ALWAYS take longer than you planned.
  3. Use ranges wherever possible. Early in a project, it at least helps to subliminally communicate to stakeholders that the project costs are still a bit squishy. I am sure we’ve all seen estimates that have line items down to the dollar. Like $365,750.00. That’s a terrible thing to do – it implies a precision that just isn’t there.
  4. Don’t EVER leave out contingency! At the project outset, make sure it’s 25% of the total project estimate. And try your best NOT to tell anyone it’s there. That’s YOUR insurance policy to keep you out of the croc pond…
  5. Get estimates from multiple sources if possible. Have a technical team do an estimate. Have a trusted project manager do one. And maybe even ask the stakeholders what they think the project should If the numbers you get back are wildly variant, you have a lot of work to do to rationalize them down to something plausible.
  6. Relentlessly track your actual costs as you incur them! And more importantly, once you see them drifting away from the estimate or any underlying assumptions you made, TELL someone right away. Delivering financial bad news is one thing; delivering financial bad news 75% through a project is PM malpractice.
  7. Figure out who, if anyone, is likely to be joining you in the croc pool. Trust their numbers more than someone who will skate out the side door faster than Usain Bolt if the project costs start going sideways.

rb-

We have all been there, in the croc pond, under the bus or in front of the train. Some one didn’t complete their task on time or misunderstood a requirement or just screwed up. These suggestions can help insulate you from some of the inevitable problems that are part of being a project manager.

Related articles

Ralph Bach has blogged from his Bach Seat about IT, careers and anything else that catches his attention since 2005. You can follow me at Facebook and Twitter. Email the Bach Seat here.

Demand for PM’s Dropping

Demand for PM's DroppingThe role of the IT project manager is critical, as new technology adoption, regulatory compliance, outsourcing, and other factors make it vital that projects be properly planned and controlled.

 few organizations properly staff the project manager functionComputer Economics says that too few organizations adequately staff the project manager function and, as a result, too many projects fall short of objectives, miss deadlines, or overrun budgets. In their report, IT Project Management Staffing Ratios (Reg. Req.), the research firm found that project managers as a percentage of the IT staff dropped slightly at the median from 4.8% in 2015 to 4.5% in 2016.

Computer Economics trend in Project Managers as a Percentage of IT Staff
The Irvine, CA based firm speculates that there are a variety of reasons for the recent decline in the percentage of project managers. They found that like other IT functions, the staffing ratio for project managers is in flux. The percentages of staff in certain other IT job categories are growing, with a higher percentage going to application development, business analytics, and security. This, by definition, pushes down the percentage in project management.

Project managerOther reasons Computer Economics cites include the improvement in project management tools, which might allow project managers to handle more projects. It also appears a small number of companies might be abandoning the dedicated role of project manager, combining it with the role of lead developer, for example. The study also blames the growing popularity of agile development, with its focus on, also may be contributing to the decline in project management as a discrete function. However, this decline has only been recent and may not yet reflect a trend. Tom Dunlap, research director for Computer Economics said,

Despite the slight drop in the percentage of PMs, I’d be surprised if that turned into a long-term trend. With the rapidly changing nature of technology in the enterprise and the generally bad track record of IT departments getting projects in on time and on budget, I expect the percentage of PMs to go up.

rb-

Compare this data to that PMI reported in their Project Management Job Growth and Talent Gap 2017–2027 (PDF) report where they are making the case for a growing job market for PM’s. The report claims that through 2027, the global project management-oriented labor force in seven project-oriented sectors is expected to grow by 33 percent, or nearly 22 million new jobs.

Related articles

Ralph Bach has blogged from his Bach Seat about IT, careers and anything else that catches his attention since 2005. You can follow me at Facebook and Twitter. Email the Bach Seat here.

Should You Say Something?

Should You Say Something?Recently cam across a post from Oisín Grogan, the “$200 Million Business Coach” about why people hate meetings. He says it’s because:

  1. They don’t start on time..
  2. They don’t finish on time..
  3. What’s in the middle is a waste of time!

Poject meetingHe stresses the project manager running the meeting needs to keep people on-point. Project team members should only talk about matters related to their roles. The sales manager should not talk about how production should be delivering. The team should talk about how to get tasks completed.

Coordination between different departments and roles is a vital function of meetings and Mr. Grogan says you’ll get more of it if you keep people on-point. To help address the issue, he developed a flow chart on how to decide when to and how to say something in a meeting.
Oisín Grogan WAIT

rb-

What do you think? Should this be handed out at the project kickoff meeting to set the rules.

 

Ralph Bach has been in IT for fifteen years and has blogged from his Bach Seat about IT, careers and anything else that catches his attention since 2005. You can follow me at Facebook and Twitter. Email the Bach Seat here.

Stop Having These Meetings

Stop Having These MeetingsFollowers of the Bach Seat know that passwords suck. As a Project Manager, something that also sucks are bad meetings. Meetings that don’t have an agenda or a goal or a purpose will suck the motivation out of people coming to the meeting. In the interest of having fewer sucky meetings here are some meetings your team will thank you for eliminating or fixing.

The Monday Morning Staff MeetingsThe Monday Morning Staff Meetings – The problem with this meeting is that no one is ever ready for it. After all, it’s 8:00 a.m. on Monday morning—nothing has happened yet and whatever happened last week is mostly ancient history. The second problem with this meeting is that for anyone to be ready, they have to work Sunday night which is fine on occasion, but guaranteed to earn you some serious votes for “jerk of the year” from employees and the family members of employees. For a while I worked for an insomniac boss who would fire off emails off at 2:00AM on Sunday. She would expect answers at 8:00AM meetings. It was a happy day when she moved on.

A third problem with this meeting is that stuff happens on the weekends. And stuff needs to be addressed, especially in IT. Did you change your tapes? Did you check your logs? Did you walk your data center? Are there warning lights? How many tickets are there? Who has time for a meeting? The solution: if you must run a team meeting on Monday, push it to later in the morning or early in the afternoon. Better yet, push it to Tuesday morning.

The Round-the-Table Status Meeting The Round-the-Table Status Meeting We have all been there. It’s the meeting where focus moves around the room and everybody shares their latest updates, sagas, fantasies and dreams. Sit in the wrong place and you end up as the 19th person to offer an update to a group whose bladders are over-strained and brains numb from the politically oriented updates emanating from the mouths of colleagues in far-away functions.

The solution: meet if you must, but set some rules on the updates. Ask people to focus on important news that impacts everyone or to challenges that need help from across functions. Do anything to limit the painful march of gratuitous and self-serving status updates that undisciplined round-the-table meetings generate.

Recurring Meetings that Have Lost Their PurposeRecurring Meetings that Have Lost Their Purpose – Any recurring meeting where no one can remember why this meeting still takes place is a candidate for immediate elimination. The laws of physics transfer to meetings and a meeting on the schedule tends to stay on the schedule long after it has used up its usefulness in the workplace.

The solution: review all the recurring meetings that you subject your team to or that you are a participant in, and drop them from your life and the lives of your team members. If you are not the host of the meeting, tell the host of your intention and of your perspective on the utility of the meeting. If you are the host/sponsor, poll team members and give them a voice and a vote. A bit of draconian slicing of recurring meetings opens up valuable time for other more important activities.

Group Word-smithing MeetingsWordsmithing Meetings – This is any meeting where you pull together a group of people to work on the wording for something: a vision, a mission, a strategy statement, a scope statement in project management. The output of these sessions is typically a series of awkwardly constructed sentences reflecting compromises on the part of the person-in-charge. No one in the room agrees with the final product, but everyone nods their heads in assent as soon as the wording moves beyond ridiculous to just awful in trying to make the pain go away.

The solution: never relegate rough wording of anything to a committee. Take a stab at the item in question yourself, bounce it off a few colleagues and when you approach something that is beginning to work for you, very carefully ask for comments from a group. Ask clarifying questions, take great notes and then disappear and redraft the statement(s), repeating the process as necessary.

Death by PowerPointDeath by PowerPoint is a phenomenon that can make any meeting suck. The poor use of presentation software causes Death by PowerPoint (DBPP) according to TargetTech. Key contributors to DBPP include confusing graphics, slides with too much text and presenters whose idea of a good presentation is to read 40 slides out loud.

When an audience remains emotionally disconnected from the presentation, there is a good chance that the speaker has either not spent enough time and effort thinking about which key points he wants the audience to take away — or he has spent entirely too much time and effort setting up the presentation in PowerPoint. DBPP can be avoided if the speaker uses the technology as a visual aid to enhance what is being said, instead of relying on the technology to serve as the focus of the presentation. Don McMillan demonstrates what not to do with PowerPoint in his video “Life after Death by PowerPoint.”

Meetings are opportunities ripe for overuse and even abuse. Strive to be the manager that respects the power and importance of meetings. Use these forums to focus on key issues and solicit ideas. To keep your meetings constructive you need to start with respect.

Respect the time that everyone puts into the sessions. Start your meetings on time. If your meeting starts on time there are fewer chances to derail other productivity throughout the day. Starting on time also helps you to end on time. This is crucial, because once the time slot for the meeting is over, employees will start to mentally check out whether you’ve made it through the agenda.

rb-

Bad meetings suck so much that the Project Management Institute (PMI) added a section to the Project Management Book of Knowledge (PMBOK) on meetings. that right – In version 5 of the PMBOK Integration Knowledge Area, there are four processes that have “Meetings” as a Tool & Techniques.

  • 4.3 Direct and Manage Project Work
  • 4.4 Monitor and Control Project Work
  • 4.5 Perform Integrated Change Control
  • 4.6 Close Project or Phase

Ralph Bach has blogged from his Bach Seat about IT, careers and anything else that catches his attention since 2005. You can follow me at Facebook and Twitter. Email the Bach Seat here.

Tips to Blend Agile, Waterfall

Tips to Blend Agile, WaterfallThere is a battle waging for the hearts and minds of project managers. The battle is between Agile advocates and Waterfall supporters according to Eric Morgan, in a recent FierceCIO article. The CEO of AtTask explains that Agile loyalists see the benefit of empowering people and teams in a bottom-up approach that produces a faster, more responsive way of working.  Meanwhile, traditionalists prefer a top-down Waterfall approach that neatly outlines all the steps in the project and defines the scope, budget and schedule upfront–minimizing risk and uncertainty.

Right or wrong?So who is right? The article says neither. Rather the article says that organizations with successful development cycles seem to use a mixed approach, using both methodologies for different projects. They cite Amazon (AMZN), an Agile powerhouse, could not have built s core web services product without some top-down dictation of standards. According to the AtTask CEO, the real difficulty for organizations, therefore, lies not in choosing one methodology over the other, but in successfully mixing the two methodologies.

Whether your organization is already juggling multiple methodologies or is considering adding Agile into the project management mix, here are four tips from the AtTask CEO on how to hybridize without sacrificing the visibility and productivity you need:

Scrum1. Transition slowly – The biggest issue organizations face in adopting or expanding Agile is the cultural transition. Change is never easy, and moving from a top-down culture of command and control to a bottom-up approach where workers self-organize and self-prioritize will certainly test your leadership team. the article stresses it’s a cultural transition that many people in an organization feel is disruptive and too much of a challenge to the established culture. To make the transition smoother and improve adoption, you should try to slow down your process transition. Understand that onboarding a system like Agile is a long-term commitment, and because only certain teams will benefit from its methodology, make sure that your organization takes the time to strategically consider where it would be most effective. Define upfront what you are trying to accomplish with Agile so everyone can understand the benefits. In addition, developing a culture of respect and appreciation for both methodologies within the organization is important. Acknowledge what works well with Waterfall and when it is most appropriate to use. This extra effort will build trust; make people more open and resilient to trying new methods; increase buy-in from management and team members; and ensure that everyone is on the same page and trying to accomplish the same goals.

2. Provide professional training – With dozens of different aspects and processes, Agile is complex. The AtTask CEO warns that one of the biggest strategic mistakes organizations make is not getting professional training at the start. In particular, it is crucial that middle management participates in training. “Middle management really holds the keys to the success of Agile adoption. They create all of the procedures and policies. If middle is not on board, transformation will be shunned,” says Dean Leffingwell, author of “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.” When middle management is properly trained, not only do they understand the value of Agile for themselves, but they can be influential in mentoring the team and in demonstrating the value of Agile to the leadership.

Communications3. Allow teams to communicate across methodologies – In many organizations, Agile teams often become insulated from the rest of the organization. According to Mr. Morgan, they work in a kind of a bubble, rarely interfacing with other teams or departments. However, communication and collaboration are two of the most critical elements of an effective mixed-methodology enterprise. Finding a way to enable visibility and communication across distributed teams, such as developing standard processes for organizing requirements and cross-team development, ensuring comprehensive release visibility for both upstream and downstream stakeholders, and managing the entire work life-cycle within one tool, will make hybrid organizations much more productive.

4. Speak a language everyone understands – The nuanced terminology associated with Agile is often an area ripe for miscommunication according to the author. In addition to making sure everyone understands the terminology and is speaking the same language, it’s important to identify key data points, such as what the team is working on, where the team is along their work process, and when the team will complete the task. Then, translate the data points into either methodology. No matter what methodology your individual teams choose, the work being done ultimately must be visible to the organization’s management and executive teams. Because manager reports and dashboards tend to focus on Waterfall-centric metrics, Agile teams need to ensure they are able to translate their results and progress accordingly. Moving to a mixed management style will always present challenges.

The articles concludes that adoption may happen in baby steps, and not leaps and bounds. Following these four tips, however, can make implementation much more successful and enable you to structure projects in a more productive way to meet your business goals.

rb-

I have talked to several grey-hair PM’s and they have basically told me that Agile/Scrum is the best tool when you don’t know what you want and use PMBOK when you know what you want?

Ralph Bach has blogged from his Bach Seat about IT, careers and anything else that catches his attention since 2005. You can follow me at Facebook and Twitter. Email the Bach Seat here.