The Requirements Frustration Factor

Posted by Brad Egeland

I’ve written a lot about requirements and how critical they are to getting a project off the ground and headed in the right direction. In the long run on a project good requirements are important for the following reasons and more:

  • Keeping the project aligned with original goals
  • Keeping the project on time
  • Keeping the project on budget
  • Scope management
  • Customer satisfaction
  • Ease of development and minimizing re-work

When I’ve discussed requirements up to this point I’ve usually been referring to them in terms of larger engagements with formal, external customers. When you’re dealing with a cut and dried contract with an external customer, you have a SOW to work against, a set budget and change management is critical as is customer satisfaction, so therefore requirements and scope management are critical as well.

Internal Fiasco

So, what happens when you get an add-on internal project for an influential person within the organization and the requirements are somewhat grey? I had a project like this not very long ago. I was asked to run a project with the basic direction of ‘just do it’ along with my other projects and ‘make them happy.’ Fun!

When one of these falls in your lap, you can try to formalize things as much as possible and wrap good project management practices around it, but if the customer (in this case, internal customer) is not interested or willing to participate and at that point considers it frivolous attention to too much detail, what do you do? That’s the quandary…because I can tell you what happens if you don’t do enough.

I thought I was getting my hands around it… I met with the customer on requirements, documented them at the most detailed level I could since I was only working with the information I was able to drag out of them. They were basically ‘approved’ as I had documented and communicated them.

The bad news is that three months later at the completion of this small one-off process improvement project, one area was lacking the proper detail that this customer now wanted. (Notice I’m not going into too much detail here – it would not be in anyone’s best interest nor is it important for the point I’m trying to make.) Forget that fact that I had asked about this particular area of the requirements on two separate occasions and confirmed that we were like-minded…at least as far as I could tell with the minimal involvement the customer wanted to take at that time.

Of course, in the end the only real solution is to fix the issue and move on, which is what I did. But I’m looking back and trying to figure out how I could have avoided that train wreck with some different corrective action during the requirements definition period. Since it’s an important, visible, and powerful internal customer, playing the blame game really does no good…it’s still all about customer satisfaction no matter who’s right.

Lessons Learned

If this were to occur in the future, and I was still unable to gain the proper involvement from the actual customer, I would likely request that they appoint an individual to work directly with me in detail on documenting and finalizing the exact requirements. That is my lessons learned from this situation. That way, the internal customer truly has better representation in the process because they will assign a dedicated individual whose job will be to ensure accuracy on the customer side. Whereas, in the situation I was involved with I had that responsibility as well as the delivery responsibility and the end result needed re-work before it fully met what the customer wanted.

Unfortunately, I unwittingly walked into one of those “I’ll know it when I see it” type customer situations that we all want to avoid. I find that those are much easier to avoid when the customer is external and knows up front that they are paying extra for everything not documented as a requirement.

Project Management Co-ordinator, Scope

Posted by Arjun Thomas

Employer: Scope
Location: London N7 9PW
Sector: Charity & volunteering support , Social care & welfare
Contract: Permanent
Hours: Full Time
Position: Project Management Co-ordinator
Salary: £20,492 – £23,522

Scope Head Office

Market Road

London N7 9PW

£20,492 – £23,522 plus inner London weighting (currently £3,089 pa)

Scope has recently designed a project management approach to meet the particular needs and appetite of the organisation without compromising on best practice methodology and the experiences of other organisations.

This role is to make use of and continuously improve Scope’s ‘Practical Project Management’ approach to support project managers across the organisation to successfully deliver projects by underpinning them with a clear, concise, corporately consistent approach.

Ensuring best practice project management in this way is vital in supporting senior management to make well informed decisions around sanctioning projects and therefore directly contributes towards Scope’s aim of becoming a financially sustainable organisation, which encompasses open, transparent, and equitable corporate process.

If you are highly organised and able to keep track of documents which are amended through a high number of iterations / version this could be the role for you.

You will have exemplary organisational skills and time management and be able to demonstrate interest in and enthusiasm for project, programme, portfolio management.

With excellent written and verbal communication skills incorporating language and style that is appropriate to a wide variety of situations and audiences you will be proficient in common IT software (MS Word and MSExcel) and have the ability to develop key relationships at all levels across the organisational hierarchy, along with strong negotiating and influencing skills

Experience of encouraging and motivating others to learn and develop, by clear guidance and feedback on performance is essential as is the ability to demonstrate commitment to personal development and continuous improvement.

Apply here..

Sensitive Data Often Exits with Employees

Posted by Brad Egeland

I’m not sure how this relates directly to Project Management. It really doesn’t, I guess, other than the fact that when employees exit many times they’re actively working on one of our projects and the same findings you read about below can affect your customers on the projects you manage in addition to the company you work for.

Dr. Larry Ponemon put together this document back in February on “Data Loss Risks During Downsizing”. I’m only including a portion of it here that outlines some of the key findings of national study performed by the Ponemon Institute and sponsored by Symantec.

The bottom line is that 59% of employees who leave or are asked to leave are stealing company data. And 79% admit that their former employer did not permit them to leave with the company data. The lack of care some companies take in ensuring that they’re protected when employees leave still amazes me.

Please read on…I’ll provide a link to the full study at the end of this article…

Key Findings

Following are the most salient findings of this survey research. Please note that most of the results are displayed in bar chart format. The actual data utilized in each figure and referenced in the paper can be found in the percentage frequency tables attached as the Appendix to this paper.

Employees are stealing data and are more likely to do so when they don’t trust their employer. According to 63% of respondents, their previous job required them to access and use proprietary information such as customer data, contact lists, employee records, financial reports, confidential business documents, software tools or other intellectual properties. More than 59% report that they kept company data after leaving their employer. It is very interesting to note that employees who do not trust their former employer to act with integrity and fairness are more likely to take the data. Sixty-one percent of respondents who were negative about the company took data while only 26% of those with a favorable view took data.

Employees are stealing proprietary and confidential data that might affect their former company’s business competitiveness and could result in a data breach. Sixty-five percent of those respondents who admit they took data left with email lists followed by 45% who took non-financial business information and 39% took customer information, including contact lists.

The most susceptible documents to theft are email lists and hardcopy files. Sixty-four percent of respondents took email history and hardcopy files (62%). Of least interest to employees are PDF files (9%), access database files (8%) and source code (3%).

Employees are stealing data in different ways. It is interesting that most employees (61%) who stole valuable customer and other business information are taking it in the form of paper documents or hard files. The next most popular means of transferring data is by downloading information onto a CD or DVD (53%) or onto a USB memory stick (42%) followed by sending documents as attachments to a personal email account (38%).

Employees who take company data are defying company rules. Of those employees who admit to stealing company information, 79% report they do not have permission to do so and 5% are unsure. The top reasons given for stealing data include: “everyone else is doing it, the information may be useful to me in the future, I was instrumental in creating this information, the company can’t trace the information back to me and the company does not deserve to keep this information.”

Only 16% say they were permitted to keep sensitive, confidential or proprietary information. However, their reasons are suspect. Specifically, the top two reasons for their belief that it was acceptable are “other laid-off employees kept this information when they left the company (54%) and no one checked their belongings when they left the company (50%).” Only 11% report that their former supervisor said it was permissible to keep this information.

Companies are failing to take proper steps to stop data theft. While a small number (4%) of employees told their employers that they were taking data, only 15% of companies conducted a review or performed an audit of the paper and/or electronic documents that employees were taken. If they did, respondents report that it was not complete (45%), or worse, superficial (29%). Approximately 41% of respondents say the review was conducted by their direct supervisor or manager followed by the human resources personnel. Approximately 89% report that their company did not do an electronic scan of devices such a portable data-bearing equipment or USB memory sticks.

Employees leave their laptops but take CDs, USB memory sticks and PDAs. Ninety-two percent of employees took CDs/DVDs followed by USB memory sticks (73%) and PDAs (17%). Only 9% kept their Blackberry and 3% kept their laptops.

Employees were able to access their former employer’s computer system or network after departure. According to 24% of respondents, their ability to access data continued after they left the company creating a data security risk. Of these respondents, 32% say that they accessed the system and their credentials worked and 38% say their co-workers told them that their access rights continued. In the case of 35% of the respondents, access to the system continued one week or longer.

While only 4% report that they gained access using a co-worker’s authentication credentials after departure from the company, 51% said their supervisor told them they would have access to the company’s system, email or network for a specified period of time. More than 44% continued to receive email on their company’s account.

Employees’ reasons for leaving are mixed. Approximately 37% were asked to leave, 38% found a new job and 21% moved on because they are anticipating a layoff. Immediately after leaving their former company, 61% took paper documents or hard files, 53% downloaded information onto a CD or DVD and 42% downloaded information onto a USB memory stick.

Implications and recommendations for companies

All companies share the potential risk of having a data breach because of the actions of former employees. In addition, they have allowed competitive information about customers, business partners and other intellectual property to walk out the door putting them at a competitive disadvantage. We recommend that companies immediately assess the potential data loss from former employees who had access to sensitive and confidential data as part of their job.

Dr. Larry Ponemon presented this paper entitled “Data Loss Risks During Downsizing” on February 23, 2009. To read the full 24-page study, go here.

PMTips: What We’re Here For

Posted by Brad Egeland

After 372 posts, nearly 500 reader and author comments and almost a quarter of a million words written over the past 7+ months, I’d like to take a moment to step back and discuss what we’re trying to do on the PMTips site.

First, let me say that this has been an extremely interesting and challenging twist on Project Management for me. To actually put thoughts to writing on past experiences, ideas, headaches, mistakes, frustrations and of course successes has been very rewarding for me. I find myself always looking forward to the next article and working to come up with fresh ideas to share or information from favorite articles or books that others may not have run across yet.

The PMTips “About” tab states the following….

PMtips.net is a blog about project management, collaboration, knowledge management and all other work 2.0 concepts present in today’s web 2.0 world.

This is a collaborative project that has several authors each of them master in the field. The purpose of this blog is to offer practical tips, tricks how-to`s and to serve as a resource for shedding light on the tools, trends, and practices that can make the life easier for many of use dealing with different challenges on a daily basis.

Its wished-for audience are those who do not use PM tools and are not seeing themselves as PM’s, but actually they do their work; people who just started being PM’s in organizations, small, medium, or larger, and are constantly searching out answers that can help them do their work more efficiently and profitably.

At PMtips.net every day new posts are posted which will help you win in your business. We invite you to visit us often and to share your insight with this community as well, since without having you as part of the conversation our aspiration to be helpful will become harder to achieve.

Looking at paragraph #3 I think we’ve gone far beyond that. We strive to be a good, useful resource to new PMs, but the comments and challenging feedback we get from experienced PMs helps to motivate the writers here and has forced our readers and our authors to think about certain PM topics in new and innovative ways.

As always, though, were are here to help PMs who are struggling or need information and answers. I’ve personally sent out more than 50 copies each of Risk Management Plans and Project Communication Plans after writing articles about each and offering templates. We’re just PMs like everyone else out there, but if there are needs for these types of tools – whether we’ve written about them or not – or questions that need answered on topics not yet covered, always feel free to send us those thoughts either through a comment or directly to an author at their email address. The door is always open.

Thanks again for reading and I am personally looking forward to much more interaction with our reader base.

Taking Steps Toward Better Resource Management

Posted by Brad Egeland

This post is basically the intended “Part 2” that I never got around to back in February when I published “Project Management and Startups: Resource Allocation and Usage – Part 1.”

In all of my years of Project Management one of the most frustrating parts has been managing resources. It’s hard enough managing resources on your own project or projects, but the bigger issue is that usually those resources are working on another project as well. And here I’m only talking about the ‘people resources.’ These are the living, breathing resources that can tell you what they’re doing and the other projects they’re working on for other PMs. At least when you hear it verbalized like that, you can do so compartmentalizing in your head of what they have going on, what their current priorities are, and what their general availability is to perform next week’s critical task for you on Project ‘Y’.

When you’re dealing with equipment resources, then you’ve brought into view an entirely different variable…and problem…that makes resource management an even more difficult task. Equipment resources can speak for themselves, don’t understand what critical tasks you have assigned to them and certainly can’t work harder and faster to make it seem like they’re doing two tasks at once. In fact, equipment resources can never multi-task.

Case Study – Privately Owned Las Vegas Company

A couple of years ago I connected with a Las Vegas company that is sort of in the entertainment industry. They supply mechanical automation and control equipment to the theatrical, themed attractions, motion pictures, and touring production markets. So there were two things different for me about this type of project management consulting work….

  • It wasn’t a typical IT project – in fact it really wasn’t IT at all. The PMs were not your typical PMs…they were more like project administrators or even gate keepers. Operations had accountability to the CEO for the projects. The PMs did not really ‘own’ the projects like we would think of PMs owning projects.
  • It had a strange cool factor. Their equipment was used for shows I had been to on the strip, movie stunts I had watched in theatres, and theme park rides I had been on.

At any rate, it definitely forced me to change some of my thought processes as I tried to build processes around what they were trying to do project-wise and for resource management. They lacked project templates, that’s for sure, and I helped them build those by first reviewing their open projects, then understanding the project flows, and finally understanding what a ‘typical’ project usually consists of.

The Issue

The bigger issue – and the real reason they called me in – was to help them figure out how to manage their resources. The great sales guy up front was the CEO and he was good at making sales…which meant he was also good at over-committing resources. They had a great reputation of supplying a great product on time and when show and movie releases depend on it your reputation can sink fast if you don’t deliver.

This may seem simple to some of the readers here, but it was news to them. First we inventoried all of their resources – people and equipment. As you can imagine, with this type of operation most of their resources were equipment. Both the equipment for the productions and the equipment to make the equipment for the productions had to be managed – since they actually made most of their own equipment in-house.

The Solution

To do this, I utilized MS Project – as I had done for their other projects and future projects as we crammed them into the templates I had created for them. I then loaded all resources, with cost rates, codes, etc. into a separate MS Project schedule to be utilized as a shared resource pool. We then linked all current projects to this pool meaning that the projects themselves did not have resources loaded – they were tracked in the separate shared resource pool MS Project file.

It worked great and it gave the PMs, the Operations Manager, and the CEO excellent insight into where their resource commitments were today and two months down the road as they were looking to had more customers and projects.

Other Possibilities

There are other solutions and I priced doing the whole MS Project Server and MS Project Professional combination for full collaboration. They’re a profitable shop, but something like that was more than they needed at the time. And web-based tools like ProjectOffice.net can offer good, cheap collaboration among PMs and personnel, but that wasn’t on my radar at that point in time either.