Black Hat IT Security Conferences 2010
Posted by Brad Egeland
Yesterday, I was informed that I will have the honor of receiving a complimentary media pass for next week’s Black Hat IT Security Conference and Briefings in Las Vegas as part of the 2010 Black Hat tour.
How does this affect project management or relate to project management? I’m not quite sure yet, though we all know security is something that is at or should be at the heart of every IT project – especially engagements dealing with sensitive data. That alone makes this topic very relevant to project management and to IT in general.
What is Black Hat?
The Black Hat Briefings are a series of highly technical information security conferences that bring together thought leaders from all facets of the infosec world – from the corporate and government sectors to academic and even underground researchers. The environment is strictly vendor-neutral and focused on the sharing of practical insights and timely, actionable knowledge. Black Hat remains the best and biggest event of its kind, unique in its ability to define tomorrow’s information security landscape.
In addition to the large number of short, topical presentations in the Briefings, Black Hat also provides hands-on, high-intensity, multi-day Trainings. The Training sessions are provided by some of the most respected experts in the world and many also provide formal certifications to qualifying attendees. Arrangements can also be made to bring Black Hat’s trainers to your location for private and customized training.
Making Good Project Decisions
Posted by Brad Egeland
Decision-making is an ongoing task on every project engagement. Key decisions have to be made throughout by everyone including the project manager, the project team members, the customer, executive management, and usually other stakeholders. They may be as simple as when to hold a meeting or as difficult as making a go- no-go decision on a phase of the project or the entire project.
What we often lack when making some key decisions is the right information at the right time. We all know that making what seems to be the right decision based on information that ends up being inaccurate or out of date can be fatal to the project.
What if you could only make decisions on when to cross the street based on a snapshot taken five minutes ago? Would this help? Would you have any confidence in whether or not you should cross the street? After all, it could be a life or death decision.
Well, that’s often how organizations are continually making business and technology decisions. Many decisions we make on projects are based on what we knew two days ago or two weeks ago or what someone told us last Thursday. Ideally, information would be flowing to all key personnel constantly and we would be making key business, project, and technology decisions based on what we just learned – not what we knew last week. What if you could make sense of what you learn as fast as you learn it and put that into play?
There is no magic wand to wave to make this all happen. However, since the project manager is the key focal point for all communication on the project, there are some things – or at least some actions – that can be put into place that will help ensure that the right information is getting to the right people as quickly as possible. And that, in turn, should help ensure that the project decisions that are made are based on the most relevant and accurate information possible.
These are:
Develop and distribute a communication plan
The key to getting all of this communication off on the right foot is to publish a communication plan for the project at the outset. Produce this document shortly after kickoff and let it document and set the tone for all communication that will flow on the project. This document will correctly set expectations of how, when, where and through who communication will happen. For more information on the project communication plan, please read an earlier article of mine on the topic here. You can also download a copy of one of my actual project communication plans to use as a template. Go to www.bradegeland.com and navigate to the Templates & Downloads page to access the sample plan.
Accidental project managers
Posted by Elizabeth
At a recent British Computer Society Project Management Specialist Group meeting in London, Miles Shepherd said that people of his generation “became project managers by accident,” often as a result of having an engineering background.
Accidental project management is the way that many project managers are created, even now. Bas de Baar has written a book called Surprise! Now You’re a Software Project Manager that is specifically designed for software engineers who wake up one day and find themselves with the new job title of ‘project manager’ and have to take on the mystery art of getting things done on time, on budget and on scope.
I also became a project manager by accident – kind of. When I was at school I didn’t know project management as a discipline even existed. I wrote lists, I did my university work in a structured and organised manner, but no one ever told me that I was managing projects and that I could make a career out of it. And I never asked. Once I was working, I saw people doing project management jobs and realised that was what I wanted to do myself. Knowing that project management roles existed was the first part of getting into it, but once I realised that I specifically sought out roles to apply for in the business change and project management sphere.
Should Requirement Quality be Measured?
Posted by Brad EgelandMeasuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.
If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.
Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects. Read more »
Scoping the Project for Better Requirements
Posted by Brad EgelandGood scope before requirements
The earlier you define scope, the more efficient your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces debates.
If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself. Read more »

