Tag: Plan

Manage Your Projects in 60 Minutes a Day

Written by Brad Egeland on September 13, 2016. Posted in Articles. 7 Comments on Manage Your Projects in 60 Minutes a Day

60 minutes. There are 24 of these segments in each day. What can I do in 60 minutes each day?

Well, you can watch your favorite one-hour TV show and still have 18 minutes left over if you record it and skip through the commercials. You can order a pizza and pick it up or have it delivered. Apparently, Bruce Springsteen is now doing nearly four-hour concerts on occasion, so you can see a few songs of one of his concert in an hour. But I think you can also manage your projects in an hour. Yes, one hour – each day. Am I crazy? Maybe, but read on.

I’m not one for multi-tasking. I don’t think men are really good at it – it’s how our brains work. So, if you happen to be overseeing say, 5-6 projects at a time, then spend 60 minutes each day on each project. Certainly, if you have a project that really requires it, spend more time. Maybe one is running full steam ahead, and two are not seeing much action at the moment. Spend two hours on the one that needs it and 30 minutes each on the two that are not requiring much attention right now. But, I think you get the picture – basically an hour per project per day should be the goal. Every project needs some daily attention. And what do we do during that 60 minutes of project-specific project management each day? Focus on these general areas and you’ll be covered every day and every week on every project on anything and everything major AND you’ll be initiating the communication to ensure that the little things do not fall through the cracks.

(Note: keep in mind that this is a general list of tasks that need addressed at least weekly, but not all need to be addressed daily. Make sure you hit all of these at some time during the week when you’re spending your 60 minutes managing each project).

Revise and distribute the weekly project schedule. Using information gathered from your project team via email, phone calls and/or a weekly internal project team gathering, you will need to use a good portion of one day’s 60 minute allotment on a detailed revision of the project schedule, including task progresses, resource assignments, new dates, and any additional work that needs to be added to the project. And be sure to ask for feedback – this is your chance to make sure key needed updates haven’t fallen through the cracks and you can be putting the onus on those all-important project stakeholders to take a good look at the schedule and give them another chance to get any updates into you that they haven’t already covered. If you don’t ask for them, you won’t get them.

Create the weekly status reporting to all stakeholders. Every week we need to spend time preparing a formal status report that – along with the revised project schedule – drives a weekly formal status call with the project customer. This activity, done weekly, shouldn’t take too long – especially if you’re spending focused time every day managing each of your assigned projects. From my experience, though, on the larger, more complex projects this will likely take most of one day’s 60 minute allotment. And just as you do with the revised project schedule and distribution – ask for feedback and updates. Make the stakeholders look at it with fresh eyes and put the responsibility in their hands to actually read it and provide you with any missing updates. I find – through this method – that there is at least one missing an update or key piece of information from at least one stakeholder every week.

Take care of any mail/phone calls and face-to-face discussions that need to happen with the customer and project team and other stakeholders. Regular connection – whether there is much to say or not – is great for keeping project team members and the customer engaged and on task. Included in this is weekly meetings that every project of any real size should be having. You can see where your 60 minutes can really start to get consumed through just keeping in contact with everyone. Communication is Job One for the project manager. Period. Nothing is more important to project success.

Check the resource forecast. Every week time must be spent analyzing your current resource needs on each project and ensuring the availability of your resources today, tomorrow and for the remainder of the project. You do not want surprises. Do this regularly and you won’t be surprised.

Revise the project budget with update actuals and re-forecast. Just like resources need to be examined regularly – at least weekly – the budget health needs the same scrutiny. A budget will almost never get out of hand if you’re on top of it regularly with close observation, frequent revision, and regular forecasting and re-forecasting. Flags can go up almost before there is a problem – while corrective action can still be effective. As I always say, a 10% budget overrun is fixable. A 50% budget overrun likely is not. If you are watching the project budget closely and re-forecasting every week – then you’re on top of it. And it will never likely go outside of that acceptable 10% variance range.

Summary / call for input

We often spend most of our days reactively putting out fires on our projects. What if we just stayed ahead of the game as much as possible with good project management focused on each project every day? What if we didn’t let any project go unmanaged for more than 24 hours. I’m not saying we do, but often we are reacting rather than being proactive.

What would go on your weekly/daily list of project management activities to stay on top of for each of your project engagements? Do you think the 60 minute daily project management scenario works? Please share your thoughts.

5 SDLC Project Management Pitfalls and how to Avoid Them

Written by Cassandra Naji on July 27, 2016. Posted in Articles. 5 Comments on 5 SDLC Project Management Pitfalls and how to Avoid Them

Avoiding these 5 common pitfalls will make your next software development project more agile and cost-effective, and will result in a better product.

Successfully pulling off a project can be challenging at the best of times, and when you add tricky software development into the mix things can get a little out of control. Pitfalls pop up unannounced, from correctly time-scoping development stages to latent stakeholder lethargy. While it’s all too easy for project managers to fall foul of these 5 common problems in the software development life cycle, getting a handle on pain points can help improve management practices and streamline any future software development undertakings. Ultimately, a pain and problem free project results in lower costs, a better product and fewer headaches for the project team.

1 – Planning timeframes

A well-planned schedule is one of the keystones of a successful software development project. And while PM tools are great, even the most sophisticated tool won’t save you from unexpected glitches. Smoothing the way for the development team requires canny prioritization, clear values, and an ability to predict the true impact of team actions.

Related Article: Avoiding Top Project Pitfalls

When planning SDLC timeframes, create a detailed task list: you can find templates that will help you organize all the smaller activities needed to bring to fruition a larger goal. Writing down all the steps required to meet a target ensures that a) fewer steps are overlooked and b) each step is less likely to be under-estimated in terms of time taken to completion. Also, if a deadline starts to creep up on you, a detailed task list will help you redefine the scope: you can either adjust the schedule, reduce the number of things you were going to do, or add resources.

With a task list, nasty surprises are less likely to crop up mid-development, and it will be easier to see at a glance where you can add or pull resources or activities without negatively impacting coding.

2 – Prototyping too infrequently

Early-stage prototyping and mid-stage iterating are vital to smooth project progress, especially in agile development methodologies. Running through the full family of prototypes will iron out potential pain points without increasing spend: use paper wireframes on user testers in initial stages to work out IA; present clickable mockups when explaining the idea to the development team; build a high fidelity prototypes when you’re nearing the final stages and need to convey the highest fidelity to clients or stakeholders.

3 – Failing to anticipate problems

There’s one big reason why Project Managers don’t spend enough time planning for problems. Because they don’t want them to happen! Sadly the ostrich technique isn’t so effective. A better strategy is risk management. Risk management can be done visually in a work flowchart, which is then checked against resource conflicts and component dependencies. Once identified, you can plan around these potential problems – lengthening lead-ups, prioritizing certain pathways and freeing up resources just in case. Building pauses into the SDLC around these potential obstacles can be a great point to build in mid-cycle quality testing.

4 – Failing to allocate tasks properly

Software development is a competitive field, and sometimes everyone wants to be the hero. But ‘heroics culture’ – pulling 20-hour shifts and moving heaven and earth to get the project done – can ruin a project. Isn’t it better to be organized and obviate the need for heroics in the first place? Creating a realistic schedule in which activities and responsibilities and wisely allocated is the best approach. For example, if you’re at the coding stage, let the developers know what tasks they’ll receive through the API and the results you expect to see in their code. Then leave them alone.

In terms of team organization, be wary of putting one person onto two projects and expecting equal investment in both, and make sure you’re providing enough staff and support for each team.

5 – Failing to engage stakeholders

Even the best PM can struggle when faced with difficult or disinterested stakeholders. Trying to keep stakeholders happy and still respect scope and spend can seem impossible. If you’re managing requirements within the project, try keeping stakeholders engaged by swapping out text-heavy requirements documentation for more streamlined tech such as a prototyping tool. Within this, you can add stakeholders as a user and have them collaborate on requirements, and everyone has access to the version history – everything is traceable. Plus confirming implementation of each requirement within the tool will keep your stakeholders in the loop.

The Importance of Continuous Project Tracking

Written by Lawrence H. Putnam, Jr. on July 20, 2016. Posted in Articles. 7 Comments on The Importance of Continuous Project Tracking

Developing early software project estimates is an industry best practice, but creating those estimates is only half the battle when it comes to improving productivity.

By continually keeping the pulse of a project—measuring performance against estimates and adjusting when necessary

—teams can gain valuable insight into their software development processes. This insight can be leveraged in future development cycles, leading to more efficient production and a better bottom line.

Estimates are just the beginning. Project tracking, reforecasting, and post project review are three valuable strategies teams can employ to monitor the development process and improve outcomes.

Strategy #1: Project Tracking

Current popular methodologies, like agile, promote metrics tracking, specifically with respect to size and velocity. But all developers, agile and otherwise, should take care to ensure that they’re tracking the correct metrics, which can include:

Cumulative size produced: this can include source lines of code, agile stories, screens and so forth;
Monthly effort: the number of person months or person hours spent;
Staff: the number of full-time equivalents billing time to the project; and
Defects: how many errors are discovered.

Data can be collected weekly or monthly, depending on the project’s schedule, and, to gain the most insight, should be compared with the project’s original estimates. Then, teams should try to figure out why deviations from estimates are happening. Is there an imbalance between management and developers, leading to a lack of skilled employees needed to complete the project? Has the team introduced new tools, methods, or team members? It can take time to ramp up on production if any of these variables have been introduced.

Strategy #2: Reforecasting

Software development cycles are rarely executed exactly to plan. Team members may have been pulled away to other projects, a large number of errors may have been found, or other variables may have been introduced. Any one of these situations will cause a deviation from a project’s original estimate. When teams examine metrics and notice that deviations are happening, it is best to reforecast, or re-estimate the project.

Certain project management tools use metrics to automatically recalculate project roadmaps. These tools can give new forecasts based on the data the team provides. It is certainly more advantageous to correct deviations early, rather than waiting until the end of a development cycle and risk missed project commitments.

Whether teams use prepackaged tools or their own estimation techniques, they should inform stakeholders of revised project plans as they develop. Reforecasting provides a window into the project’s progress at regular intervals. As more data is collected and forecasts are continually refined and communicated, project transparency and accountability also improve.

Strategy #3: Post Project Review

When a project is finally finished, teams are usually ready to power down, close the books, and take a break before diving into the next big thing. The project’s level of success is often perceived as somewhat irrelevant—team members usually want to move on quickly.

However, taking time to do a post-project assessment is a great strategy to continuously improve team outcomes. Just like project tracking and re-estimating, post-project assessments provide the opportunity for a collective pulse taking.

In its most basic form, a post project review gives team members a chance to evaluate what went well and what could be improved upon for the next project. Post-project assessments also give teams chances to assemble final sets of metrics that, when examined with data previously collected on the project, may provide more accurate estimates for projects going forward.

The Bottom Line: A Better Production Cycle

Strategies such as project tracking, reforecasting, and post-project assessment all help team members refine project estimates on the fly. When updated estimates are shared with stakeholders, communication among project team members and accountability are improved.

Over time, the process of collecting data, updating trends, and using trends to estimate future projects creates a circular process that creates more refined estimations over time and across multiple project cycles. More accurate estimates can translate into happier stakeholders, a more judicious use of resources and, ultimately, a better bottom line.