Showing posts with label Project Management. Show all posts
Showing posts with label Project Management. Show all posts

Thursday, December 5, 2013

Interview red flags for the IT consultant

Sometimes the new IT consulting gig you're walking into is a mess. These early warning signs might set off your inner Geiger counter.


risk.warning.872013.jpg
For a number of years, I've practiced IT as a consultant rather than an employee, meaning I pop in and out of various companies for six to 18 months at a time. There's always a conversation up front during which the task is spelled out to me, and we see if it's a good fit.
The thing is, there's a quality spectrum to deal with: Some projects are exciting and progressive, some are necessary drudgery, and a scary few are nuclear meltdowns, requiring a sacrificial technician to wander into the hot mists. One way to detect potential meltdowns is to pick up on the early warning signs and then ask the right questions from the start.

Interview questions that are red flags

"Do you have experience with application support?"
There isn't anything farther removed from the typical IT consultant's range of interest than application support. Most of the time it doesn't come up -- it's much more likely to surface as a necessary evil in an interview for a staff augment gig.
But when a project is crashing and burning and consultants are being rapidly hired, that usually means a system in production has gone haywire and no one knows how to fix it. The project will involve rebuilding the app as well as propping it up in production in the meantime, or, at the very least, reverse-engineering the existing mess to the point that you can teach someone else how to prop it up. Do you really want a piece of that?

"Would you be comfortable working with products that are no longer supported?"

If a production app is wigging out, oftentimes it's because the legacy app is built out of parts and pieces that no one in-house has on their shelf -- the technology is so outdated that the current crop of developers are all newer than the legacy app platform. This also explains why a consultant is brought in to fix it. Most consultants have been around awhile and have hands-on experience with obsolete technologies. I was in this situation in the past year, dealing with an Adobe PDF generation system that was deployed during the Clinton administration.
If this kind of thing doesn't float your boat (it floats mine!), steer clear of it, because there's usually no surviving documentation and no one to call.

Follow-up questions you should ask

If your alarms are starting to go off, you can take some initiative to pin down exactly how messy the situation is, and this can help guide your decision about wading in.

"How many releases out of date is the platform you'll be working on?"

The rule of thumb is No More Than 2. If you're a Microsoft junkie (as I now am), two releases puts you back 4-5 years, which is an eternity in IT time. And while the typical application life cycle used to be friendly with that time span, it's less so today. If I'm sitting in an interview in 2014 and the SQL Server back end of the app to be rebuilt is SQL 2005, I'm in trouble.

There are several reasons why: If it went that long without an upgrade, it's probably been neglected through-and-through, not just on the back end; if it's a multi-tiered app, its layers are likely way out of sync, and it's probably unscalable. And the documentation (if it exists) is not likely to be very good.

"How many folks in-house have expertise in the legacy system?"
If the answer is none, you know why they called you. If the answer is one, two, or a few, your next question has nothing to do with the IT side: "Is there a business-side expert who knows the app, its users, and where it needs to be today?" If the answer to that last one is yes, then all is not lost.

Tuesday, December 3, 2013

Move from collaborations to conversations with Glip

Will Kelly reviews Glip, a new conversation platform targeting SMBs that want a better collaboration and communications solution.

Gliplogo_120213.png
Glip is a new collaboration platform that came out of stealth mode in October 2013. The company is positioning itself to be a conversation platform for small to medium businesses and is striving to differentiate itself from Asana, Skype for Business, Podio, and Yammer. 
Glip offers a 60-day free trial and pricing on a per user basis. You need an email from a company domain to sign up for a Glip account.

Dashboard

Glip has a minimalist Dashboard (Figure A) that is broken down into a weekly calendar where you can click a date and then enter event information in a pop-up dialog box. You can then post the event for the team to view or for the individual user's reference.
Below the calendar is a My Tasks list where you can enter tasks with start and end dates and assignees. There's even a column for days, which is a nice touch.
Figure A
GlipFigA_120213.png
Glip Dashboard

People

The People screen (Figure B) is where you can add the people you work with most so you can communicate with them. When Glip's PR person set up a live demo for me, all of the participants showed up in my trial account's People screen.
The real charm of Glip's people-centric platform is that you can easily bring in third parties such as clients, contractors, and freelancers on your projects. People using Glip for the first time have to download the Zoom plug-in to enable video conferencing; however, the download was quick and without the usual hassles that accompany plug-in downloads for other video conferencing and screen sharing solutions.
Figure B
GlipFigB_120213.png
Glip People

Conversations 

Teams

Glip lets you create teams around various organizational functions or projects. Conversations in Glip with three or more people take place in the Teams feature, which is equivalent to a team site or workspace in traditional collaboration platforms. Figure C shows an example of a video conversation.
Figure C
GlipFigC_120213.png
A conversation in a Glip Team
Teams and conversations are based around a central stream. I hesitate to call the stream a social stream because my first impression of Glip from the demo is that the platform takes a backseat to the conversation and communications between participants; I was able to focus more on the video chat I was having with Glip's founders and less on the tool. Even the text chat is non-intrusive when compared to similar tools I've tested.
Figure D shows the conversation options that are available to all team members.
Figure D
GlipFigD_120213.png

Conversation options

Files

Files is the one area where Glip's minimalism works against it. Glip saves any links and files that are part of the conversation for later reference by the conversation participants. When I saw the Files section on the Glip Dashboard, I was expecting to find some central point for uploading project files; at this time, that can only be done as part of the conversation.
Figure E shows the files that were part of the Glip demo conversation I had with the company's founders.
Figure E
GlipFigE_120213.png
Glip files
Integration with Google Drive and Dropbox is part of the Glip roadmap.

Account settings

Glip keeps its Account settings on the minimalist side, which is commendable. When you click Account Settings, you can modify these settings:
  • Email Notifications
  • Sound
  • Calendar Start
  • Max Conversations
  • Calendar Feed
  • Change Password

Glip API and looking ahead

While I see a lot of promise in Glip right now, the company is looking at integration options in the future through its Application Programming Interface (API) into other backend systems like bug tracking and project management platforms. Some prudent integration and partner plays by Glip could lead to this platform gaining market share in the future.

Conclusion

I didn't understand why Glip was positioning its new offering as a conversation platform vs. a collaboration platform until I had a chance to see a full demo with the Glip team. While I'm reluctant to say conversation platform will become a new branch of online collaboration and/or unified communications, Glip shows the cleanest integration of video conferencing and collaboration tools that I've seen thus far.

As with platforms from any startup, I expect to see the company and platform make changes to messaging and features as they advance in the market. Even though Glip (the company and the platform) is still in its early stages, I highly recommend checking out the trial version if your organization is looking for a more integrated collaboration and communications solution.

If you've tried Glip, share your feedback about the platform in the comments.

Saturday, November 16, 2013

University Hospitals and AtTask boost project visibility, collaboration and performance

When Andy Kinnear left CSC and joined University Hospitals as Director of Project Management, he sought a robust project and portfolio management solution that could meet and exceed the expectations of Northeast Ohio's second largest private sector employee. The answer was AtTask.

attask.jpg
In 2009, Andy Kinnear, Director of the Office of Project Management for University Hosptials (organization size: 16,000) in northeast Ohio had a problem. 
 
For close to two years he had overseen system implementations for University Hospitals (“UH”) as a senior project manager at CSC. Then UH decided to bring Andy and several of his CSC colleagues in-house. They went from having a “relatively robust” project portfolio management system to not having a budget for a portfolio solution.

“And like any good IT group,” says Andy, “we decided we would build one. We built it on an MS Access platform, and there were obviously some limitations we ran into. It did do an admirable job of providing some consistency. We did status reporting out of the database, and it was somewhat of a repository. It allowed us to keep some rudimentary dates: start, end, and percent complete. Things had to be manually updated by the project managers with this tool, and the PMs were the only individuals who has access to the database.”

Andy and his team at UH continued to have “some trials and tribulations” with the MS Access database that they developed. While they could manage projects with basic statistics and key performance indicators, they had to manually update the tool. Andy would regularly send a note to PMs two days before reporting, to remind them to get all the data entered so that senior management could have the most current information.

“I've got a portfolio manager on staff here,” explains Andy, “and I said to him: 'We need a new solution. We've got to go out and find something.' We had people who could not access the database, and also had people who could access it, but couldn't update anything. As a result we didn't have a good handle on what changes needed to be made and how to go about making those changes. We then made the decision that it was time to switch to something and we went through a selection process.”

Functionality and value in an enterprise-wide solution

Andy describes how they chose AtTask as their solution within two months. “We investigated MS Project Server as a potential solution, since UH is a Microsoft customer. We looked at some more rudimentary applications, realizing that cost was a driver for us. That was one of the selection criteria that was critical for us, because we didn't have a significant budget—it was something that we were going to have to fit within what we had available.”

The UH Project Management Office grasped the value that AtTask could bring to their organization. “As we looked at true value,” says Andy, “from the three or four applications that we considered, AtTask quickly rose to the top. Although it was more expensive than a few of the applications that we considered, and as we looked to the future, the functionality within the application far outweighed the pricing difference.”

Another driver was that they had to have an enterprise-wide application to promote performance improvement. Two years ago Andy began leading a project titled “UH Transformation.” This was a $150 million cost-down effort with 219 separate initiatives. “We created a group in the operations project management office,” says Andy, “that would be aligned with Lean 6 Sigma and push performance improvement across the health system.”

With the UH Transformation project Andy had 16 PMs and 10 operations managers, but didn't have a unified system to create visibility, ensure collaboration and boost productivity.
“The Access database was specifically built for IT projects,” explains Andy. “And so without having a developer come in and revamp it in order to handle performance improvement projects, we realized that we needed something else for that book of business.” With the AtTask Enterprise Work Management solution, they have managed their project managers and operations managers as two distinct portfolios for the past year.

“We went looking for a solution,” Andy says, “with a broad application in mind. We wanted something that would encompass performance improvement efforts, and also mergers and acquisitions. We recognized that IT was not the only group that needed project management assistance, and wanted something that supported project management as a function, not just project management as a group within a department.”

UH initially signed up with AtTask for 25 licenses, and recently has renewed for 500. Says Andy: “We've now got eight portfolios in the application supporting everything from marketing to home care to obviously the IT and performance improvement side.”

Results of AtTask solution

Here were some of the advantages Andy started to see after putting AtTask to work:

Visibility
“I really started utilizing the tool as I would present,” says Andy. “We've got a leadership team with four vice presidents, and as I would present project updates, I would just utilize the tool, because it's all real-time data with a dashboard that allows them to see how many projects there are, what programs these projects are sitting in, which ones are in trouble or at risk, and then which ones are on target. So I would just utilize them on the dashboard as I presented updates to that group.”

“When we started with AtTask,” adds Andy, “we probably had about 90 projects. We are up to 170 now.”

Collaboration and productivity
“I can talk to the fact that AtTask has really standardized the way the we work,” says Andy. “Before we would have one PM who would really like to use Excel as their plan, one that would really like to use MS Project, and one that may not have a plan written down at all—it's on a napkin. Now we've got a standard format that we're leveraging as we go to work with those resources. The learning curve on the staff side is much, much quicker, because it's a standard, they've seen it before, they know what the look and feel is.

Prioritization
“We've been able to standardize plans and tasks,” says Andy, “we've been able to increase the visibility and the accountability with these efforts within UH for the prioritization criteria that we've built within the application. We can give a project an objective view when it comes in. We score it on eight criteria, and then on its alignment score with regard to what we feel are the key drivers within the organization. I think there are things outside of those eight criteria that may factor in, but at least it provides a view of, if all things are equal, which of these projects would go first in order of priority from the organization's perspective. That's been a big win for us as well, to be able to incorporate that into some of our senior leadership discussions.”

Adoption
“From a project management perspective,” says Andy, “we've seen a significant amount of adoption within the tool. The operations engineers, although they have project management backgrounds, took a little while longer to gain that adoption. But we're there now, we're using it for all those performance improvement efforts as well.”

Resourcing
“We've got about 170 projects,” explains Andy, “just within the project portfolio that we are managing. The other thing we are setting up right now is an operations portfolio that will allow total time tracking—that's for about a year from now. And we just renewed with AtTask), so the impetus there is really complete resource tracking. Where are we spending our time, not only looking backward, but sometime next year we'll implement the resource utilization and we'll start to look forward as well.”

“The next evolution within the tool,” says Andy, “will be to get all those resources on, understanding where that time is being spent, and then really having the tool drive the speed with which we implement.

Friday, November 15, 2013

HealthCare.gov rollout lesson: Push back on unrealistic launch dates

Ken Hardin believes testing and a real sense of consequence might have helped dodge the Obamacare site launch fiasco. Read his tips for tackling forced release dates.

When my editor here at TechRepublic asked if I would be interested in writing about the project management implications of the Obamacare HealthCare.gov site fracas, my first instinct was to say it probably wasn't all (or even mostly) a project management issue in terms of formal PM disciplines. The site's rollout troubles sound more like a case of a fundamental break down in how an organization handles big projects.

Caveats: This article is not intended as either an endorsement or a criticism of the Affordable Care Act. It's also not intended to be a deep analysis of what has gone awry with the software development project. Since I didn't work on the project, I probably never will have an idea of what specifically went wrong. I will take the liberty of saying that folks who are shocked that a big ol' website launched with some significant problems have probably never worked on a big ol' web site launch, or for that matter paid very close attention to similar private-sector boondoggles that don't tend to grab headlines.
HeadinHands_101613.png
There's only so much a project manager can do when presented with unrealistic objectives and deadlines set arbitrarily by senior management (or Congress, or what have you), and that is my general impression of what went wrong on this project. I was taken by the "analysis" -- really it's just common-sense business advice -- from PM guru Dr. Harold Kerzner in this Huffington Post article. I am a sucker for any Star Wars analogy, and Kerzner draws a perfectly lucid parallel between Darth Vader threatening that the new Death Star darn well better be ready for the Emperor's visit and pushing for an unrealistic deadline just because, you know, that's when we want it.

(Spoiler: The new Death Star wasn't really "fully operational," as the Emperor boasted, unless you consider one entire exposed side just waiting to get strafed by Rebels "fully operational.")
 
But what do you do when your Dark Lord … err, executive team … announces that a project has to be completed on such a date / time, and that is how it is? The first recourse is to try to hash out accurate time / cost projections and triage off enough functionality to make the deadline at least plausible, while maintaining some core value in the deliverable. But even if you, the business analyst, and a few mid-tier managers are able to pull off a reasonable pruning exercise, the odds of you being able to squeeze in a credible effort against a purely arbitrary deadline are still slim.

Come launch day, you are likely to end up with:
a)  a gelded deliverable that does not deliver on the proposed business value.
b)  a buggy mess.
c)  both a & b
Again, dark fate A is mostly an issue of the dreaded IT / business misalignment (i.e., incompetent management) and just something project managers have to deal with, or at least try to mitigate.

I have racked my brain for several years on how to tackle the bugginess of forced releases, and I have come up with no perfect answer there, either. Once, however, I did get all the stakeholders to buy into two terms for launch that did actually result in the "hard and fast" live date slipping a bit and the client avoiding a serious data security problem.

Term 1: The prescribed QA time in the project plan could not be trimmed, under any circumstances.

Term 2: The stakeholders had to identify 15 general requirements that were non-negotiable.

Term 1 is the toughest to enforce, since QA at the tail end of a time-sensitive project always gets slashed, even though it's even more vital when developers are in a hurry. I have seen projects go live with only developer peer testing, and managers congratulating themselves over it. Argh.

You'll find an ally in the QA manager for setting Term 1, and with any luck you'll be able to push back hard on folks who agreed to the terms when they start thinking that fudging is a good idea.

Term 2 is a little dicer, and will require the help of a business analyst or a project sponsor. If at all possible, try to quantify in dollars the damage that will likely occur if the requirement is not met. And this agreed-upon list should be communicated up the food chain to the Big Guy well in advance of the launch date. It should be simple enough for senior executives to grasp; hell, put it in a PowerPoint.

Again, I cannot stress this enough: When the launch date is mandated by the Big Guy, making that date becomes a goal unto itself, regardless if the actual product is even remotely useful. That's just politics, on Capitol Hill or in your office campus.

By codifying the most essential needs of the project – "we need multiple security layers, so that teddy bears with sticks can't make us completely vulnerable to attack" -- and ensuring that the team has time enough to test those requirements, you can at least go to senior management with a very clear message as to why the project simply can't launch on a purely arbitrary date.

Would this have worked in the case of the Obamacare site? Maybe, if the project team knew about some of the more serious bugs and faced credible penalties for launching a buggy mess. Or maybe not -- the U.S. federal government is enormous, and as I said from the outset, I don't really know what happened here, and frankly have no insight into the professionalism and honesty with which those involved acted.

But here's hoping that at least in your shop, if you can clearly quantify the pain of launching just to say you launched, someone Up There will listen.

Wednesday, November 13, 2013

14 quality checks for your IT project schedule

One way to evaluate whether your project schedule is good is to measure it against this list of quality checks from the Defense Contract Management Agency.

IT project management consultants and Project Management Office (PMO) managers see project schedules that vary in quality. A PMP certified project manager (PM) may have 10 years of experience managing projects, but that isn't an indicator of the PM's ability to build a good schedule.
checklist_1.jpg
Evaluating a project schedule can be subjective unless there is a set of objective criteria to follow. Well-structured PMO organizations may have project schedule quality guidelines, but unless there's a schedule review, the schedule could still have significant defects that impact realistic project delivery. (Remember: The project schedule is a forecasted model of future events, so you want the model to reflect reality as much as possible.)
 
The Defense Contract Management Agency (DCMA) provides a 14-point assessment that can be applied to evaluate project schedule quality. The DCMS is a Department of Defense (DoD) department that works with suppliers to manage time, cost, and performance for the U.S. federal government.

Pre-assessment metrics

You need to calculate these metrics before applying the quality checks.
  1. Total Tasks is a count of the lowest level tasks, excluding summary, subproject, zero baseline duration, and milestone tasks.
  2. Complete Tasks is a count of Total Tasks with an Actual Finish date.
  3. Incomplete Tasks is a count of Total Tasks without an Actual Finish date.
  4. Baseline Count is a count of all the Total Tasks that should have completed on or before the project status date.
  5. BEI Baseline Count is a count of all the Total Tasks that should have completed on or before the project status date and all the tasks that are missing a baseline start and finish date.
  6. Relationship Count is a count of all the Finish-Start (FS), Start-to-Start (SS), Start-Finish (SF), and Finish-to-Finish (FF) dependencies in the schedule.

The 14 quality checks

  1. Logic Check evaluates if any tasks are missing a successor or a predecessor in the schedule.  Logically, all activities should have at least one predecessor or successor tasks or else you risk creating an orphaned task. A quality schedule should not have more than 5% of its tasks missing logic. The logic check formula is (# of Tasks missing Logic) / (# of Incomplete Tasks) * 100.
  2. Leads Check looks for negative lags (i.e., leads) in the schedule. A quality schedule should have zero leads, as they can impact a project's critical path.
  3. Lags Check ensures the use of lags is minimized in the project schedule, as lags can impact the critical path. A quality schedule would have fewer than 5% of the tasks with lags. The lag check formula is (# of Tasks with Lag) / (Incomplete Tasks).
  4. Relationship Types Check validates 90% of the tasks have Finish to Start relationships.  Using Finish to Start relationships provides a logical flow to the schedule.
  5. Hard Constraints Check is any activity that has a Must Finish On, Must Start On, Start No Later Than, or Finish No Later Than constraint. You often see these constraints in the "pick-a-date" project management. You ideally want your schedule to be a dynamic schedule that flows easily when the project is updated. The hard constraints check identifies any Incomplete task that has a hard constraint. A quality schedule will not have more than 5% of its tasks with hard constraints.
  6. High Float Check identifies all tasks with a total float of more than 44 working days. A task with such a high float usually indicates a predecessor or a successor was missing. The formula is (# of High Float tasks) / (# of Incomplete Tasks). The percentage should not exceed 5%.
  7. Negative Float Check identifies any tasks that have a float less than zero. This check helps identify any tasks that may hinder the completion of other tasks in the schedule. There should be zero tasks with negative float.
  8. High Duration Check identifies any task that has a baseline duration greater than 44 days.  As competent PMs, we know such tasks should be broken down into more discrete tasks. The formula is (# of High Duration tasks) / (# of Incomplete Tasks) and should not exceed 5%.
  9. Invalid Dates Check identifies any total task that has a scheduled start or finish date before the project status date and an actual start or finish date after the project status date.  Forecasted start and finish dates should always appear after the project status date. The schedule also can’t contain an actual start or finish date in the future. There should be zero tasks that fall into this category in a quality schedule.
  10. Resources Check identifies all the tasks that do not have resources (people or costs) assigned. A quality schedule has all resources assigned to tasks in the schedule.
  11. Missed Tasks Check is used to identify any task that was scheduled to complete by the project status date and finished after the baseline finish date. The reality is projects will have late tasks, but you want to ensure your current schedule re-aligns to the baseline schedule. The formula is (# of tasks with forecasted finish before the status date and actual or forecasted finish after baseline schedule date) / (baseline count).
  12. Critical Path Test Check assesses the integrity of the schedule network using the critical path. An intentional delay of 600 days is entered into the remaining duration of a critical path test. The expected result is the project is delayed by 600 days since you added a delay directly on the critical path. The schedule passes the test if the project finish date matches the added duration date finish date.
  13. Critical Path Length Index (CPLI) determines if the project finish date is realistic given the forecasted finish date. The critical path length index is calculated using the formula (Critical Path Length + Total Float) / (Critical Path Length). The value should be greater than 1.0 to pass the test.
  14. Baseline Execution Index (BEI) is similar to Earned Value's Schedule Performance Index as it compares the number of completed activities to date to the number of tasks planned to be completed by the project status date. The BEI is calculated # of Complete Tasks / BEI Baseline Count and should be greater than 1.0.

Summary

You can use these quality checks as a framework to evaluate and review project schedules.  The criteria can also help you evaluate how well a supplier can build and execute a meaningful schedule.

As a project manager, I've seen my share of bad schedules, and I'm sure I've built a poor schedule every now and then. The DCMA criteria serve as a useful schedule quality gauge that eliminates subjective evaluations. 

In my next article, I'll show how to automate some of these quality checks in your Microsoft Project schedule. 

Saturday, November 9, 2013

How to make project management a learned skill and behavior

Your IT project team might be the most powerful PM tool of all. Read experts' advice about how to get the most out of those team members.

technology-head.jpg
Last summer and more recently, I spoke with Dean Carlson, CEO of Viewpath, about the importance of project management becoming a learned skill and behavior for the entire project team, industrywide trends, and other project management-themed topics. For additional insight, I interviewed Avinoam Nowogrodski, CEO of Clarizen. Here's some of what the two gentlemen said to me.


Make project management less of a top-down planning discipline

Carlson points to lessons he's learned implementing Viewpath for a client that is a large technology company. The company has a number of professionally trained project managers and in recent years has implemented Google Apps. 

"They decided they needed to have more collaborative tools and be much more inclusive with their project management applications," says Carlson. "And, what I mean by that is they have a big contingent of Mac users that Microsoft Project doesn't play well with. They also have a big contingent of mobile, and their objective was to make project management less of a top-down planning discipline and make it much more integrated from top to bottom."

His client chose Viewpath because it let them assign tasks to a large number of contributors in contrast to the old Microsoft Project approach. Microsoft Project became a "knowledge silo" because the project managers didn't want team members making a mistake inadvertently when editing or updating the project schedule.

"So the project managers were often in a role of taking down status of where we are at with the given project, and the goal of moving to the cloud was to push accountability and visibility down to the entire organization," according to Carlson.

"Anybody at any point in time could log in and see where they were at with one or multiple projects, and those individuals could have a small sliver of what they are looking for on the project," says Carlson.

He further adds, "They interact with the applications through the tasks they can see in their area of responsibility in the project."

Carlson offers this advice about working with project managers and team members: embrace a new culture where project management is no longer just the domain of the project manager; it takes top-down planning and bottom-up execution.

"One of the keys of getting buy-in from the rank and file is providing the visibility at a macro level in the organization as well as having a clear picture of the projects on their plate," advises Carlson.

To Carlson, giving the team member in the trenches the tools and visibility across projects means team members are better informed when making commitments. Overcommitments can get very messy, especially when team members with critical skills have to reschedule their commitments on a frequent basis.

Build a culture of active voices and participation

One element of making project management a learned skill and behavior for a project team is to encourage participation, according to Nowogrodski. I call this "democratizing project management," and Nowgrodski seized on the term democracy during our discussion. "Democracy means having a voice," according to Nowogrodski. He adds, "At the end of the day, it is about creating active participation with the people you work with. Participation is being created with people who have a voice."

He notes that team members also need to understand their impact of their actions and voice through participation. He cites building an open culture as key to this and giving people a platform to speak their mind

When I asked Nowogrodski how he recommends promoting such a culture, he told met that there are three elements that help build a successful team for project success:
  • Making sure there is alignment on the project objectives
  • Value and information
  • Knowing what's coming down the pike

/var/wwwnduct bug fixing without recrimination

Working as a contract technical writer inside a number of large and small organizations, I've come to see that you can judge an organization as to how they fix their software's bugs. When mistakes lead to only recriminations and blame, it prevents a project team from doing their best work and from presenting breakthrough ideas that can benefit the product and customers. 

When bugs are documented in a centralized tracking tool and open for team members to consult others for help through Agile standups or other communication channels, it becomes a bottom-up execution vs. another top-down project management exercise.

/var/wwwnclusion

Making project management a learned skill and behavior means improving team communications and moving away from traditional top-down planning that marks so much of project management and opening up your development processes to accommodate more bottom-up execution on the part of your programmers, engineers, and other staff.

Saturday, November 2, 2013

WorkZone: project management simplicity with some rough edges

Will Kelly evaluates where the WorkZone project management platform shines and where it falls short.

WorkZone is a web-based project management platform that strives to hit the sweet spot between a complex tool like Microsoft Project and the simpler Software-as-a-Service (SaaS)-based social task management tools. The good folks at WorkZone arranged an evaluation of their platform so I could review it.

Project workspaces

Project workspaces in WorkZone are well laid out and designed; I especially like the ability to filter views by Dates, Project Responsible, and Project Category. One thing that's missing that comes with many other platforms is an activity stream.

By default, workspaces open to the Project To-Do List (Figure A), making WorkZone all business. I know of teams that would find the Project To-Do List more than a match for their project management needs because they require simplicity not a complex Gantt chart. The Project To-Do List is central to WorkZone workspaces, yet it's not necessarily where you track projects -- there is a separate Project Tracker. I wish the integration of the To-Do list and Project Tracker was more obvious; the WorkZone user interface treats them as separate entities, which feels a bit unnatural.

Figure A
WorkZoneFigA103113.png
A Project To-Do List that spans multiple workspaces. (See an enlarged view of the image.)
I don't like that you have to go under Settings and to the Setup menu to set up a new workspace vs. being able to create a workspace directly from the Select Workspace drop-down list. Granted, this is a minor nitpick, but it's a common feature in many of today's project management and collaboration platforms.

I do, however, like the ease with which you can pull up other useful views, including:
  • Projects By Responsible
  • Completed Projects
  • Active Projects 100% Complete
  • Activity: Last 7 Days

Project Tracker

The Project Tracker (Figure B) is where you can track larger and more complex projects within your WorkZone workspace. Project Tracker has filter options that help you change your views of project information (Figure C).

Figure B
WorkZoneFigB103113.jpg
Project Tracker (See an enlarged view of the image.)
Figure C
WorkZoneFigC103113.jpg
Show only TASKS that match. (See an enlarged view of the image.)

Document management and sharing features

Documents are broken down by project, and you have the option to create folders within the project. You can only upload documents from within a project or a folder.
The Document Manager tools (Figure D) are an example of how simplicity works in the platform's favor.

Figure D
WorkZoneFigD103113.jpg
Document Manager's clean layout (See an enlarged view of the image.)
Figure E shows the available WorkZone document management features.

Figure E
WorkZoneFigE103113.jpg

Documents as part of a WorkZone project (See an enlarged view of the image.)
WorkZone's document sharing features are basic but sufficient for simple document sharing and collaboration.

Project reporting

One item on my technology writer bucket list is to write a post about the end of the Microsoft Word status report. I've worked in the federal and commercial sectors, and the Word document status report always seems like more a tool of bureaucracy than project tracking.
To that end, I’m happy to see that WorkZone has a number of project reports available to track activities, including:
  • Dashboards that offer a quick view into recent activities, upcoming items, recent documents, approvals, and completed tasks.
  • Project views that offer status by project.
  • Workload by the responsible party and by category.
  • Usage summary and activity logs.
Figure F shows the Recent Activity dashboard.

Figure F
WorkzoneFigF103113.png
Recent Activity dashboard (See an enlarged view of the image.)
 
The project reporting options should be attractive to organizations with moderate to high reporting requirements. Distributed project teams can also use the WorkZone reporting features to give their management team more transparency into their projects and tasks without taxing team members with unnecessary levels of status reporting or communications.

Setup

The Setup menu governs all WorkZone workspaces. Unfortunately, a "Please select a link from the left menu" message greets you when you open the menu. In 2013, this message is a cheap out when they should have found a better use for the screen real estate.

Setup gets confusing when you click Setup at the All Workspace level, and then it sends you to a site level menu. If you're inside a workspace and click Setup, you're taken to a Workspaces level setup, which might baffle some users and even administrators. I think better delineation would help usability.

A hidden gem amongst the Setup options is Partner Firms. This feature enables you to set up secure access to partner firms for exchanging information with them. Check it out if you work for an organization that partners with other firms, contractors, or freelancers on projects.

Final thoughts

While WorkZone's design has a few rough edges and it's missing social tools like an activity feed, I find its simplicity ideal for some project delivery organizations. WorkZone is a definite option for project teams that want a solution that fits between social task management and more complex project management platforms.

Wednesday, October 30, 2013

The business analyst: The project manager's best ally

Ken Hardin shares a tale from his days as a TechRepublic manager that illustrates why PMs need a direct channel to the business analyst.

handshake_thumb_091013.jpg
Almost all prescribed remedies to scope creep relate to change management after the business requirements for a project have been set. Project managers (PMs) are trained to try to police increases in the cost and time required for the project that don't create any clear benefit for the business.


Fight scope creep with this change request trick

Ken Hardin identifies one weapon in the never-ending battle with crazy IT project scopes.

agile_projectmanagement_091913.jpg
Scope creep usually comes in second on a list of why IT projects fail, behind the dreaded IT/business alignment issues (which is a euphemism for senior management doesn't know what it's doing). You can take a swing at helping out on the alignment problem, but there are only so many reports you can send up the food chain to be ignored.