Tag: Project Management

How To Take Your Project Management Strategy To The Next Level

Written by Frank Hamilton on September 26, 2019. Posted in Articles.

Project management has always been a fundamental element of any business.

If the company executives don’t have a grasp of the key components of what their organization is doing, everything will go wrong. Here’s how you can take your project management strategy to a whole new level.

What Is Project Management About?

To put it simply, project management is about applying certain knowledge and skills as well as tools and techniques to meet specific project goals, objectives, and deliverables. It includes all the inputs and outputs that project managers and teams may use.

The goals that project management pursues can include anything from identifying and executing initiatives to acquiring the right people. It’s actually quite a broad term, but the concept is that project management professionals help achieve certain company goals by driving, guiding, and executing them.

How to Choose the Right Methodology?

In order to be able to execute your project properly, you must know and choose the best methodology that could be applied to it. Of course, it’s better to use hybrid project management methodologies for better results. Here are some of the most popular project management methodologies (PMMs):

Waterfall: The project is completed in separate stages and moves one step at a time toward the final destination which is the release to consumers.
Agile: Sprints, or short development cycles, are used to focus on continuous improvement and development of a certain product or service.
Hybrid: This method combines agile and formal project management methodology.
Critical Path Method: The most important tasks are identified from the beginning and performed prior to the tasks that can be slowed down and performed later.
Critical Chain Project Management: The method emphasizes resources such as people, equipment, and physical space needed to complete the project.

When choosing the methodology you will be using in your project management, you must keep in mind all the peculiarities of a specific project. Sometimes, you will need to use one methodology while other times you will be using something else. In addition to that, don’t forget that you can combine them from time to time if the situation requires it.

What Are PMO and EPMO?

PMO or project management office and EPMO or enterprise project management office are both umbrella organizations that companies codify project management efforts under. Both of them have some notable differences and similarities to keep in mind:

PMO: Usually doesn’t play a lead role in strategic goal alignment. It’s an external or internal group that sets directions and maintains standards, best practices, and project management status.
EPMO: It is increasingly being adopted by companies. EPMO has the same functions as PMO, but it must also align the project, program, and portfolio activities with the company’s goals.

Both PMOs and EPMOs offer more visibility throughout the organization, ground rules for the project teams, a common language for all the team members, key indicators to measure project performance, more agility and adaptability, and the ability to identify the status of various tasks.

What Are the Key Roles In Project Management?

The positions that will have to be filled by different professionals in your project management strategy will vary depending on the project, methodology, company, team, and industry. You may need the help of such people like business analysts, schedulers, sponsors, functional leads, business intelligence analysts, and others.

To get you started, here is an overview of the three key roles in the management of any project:

Project Manager: Plans, executes, monitors, controls, and closes individual projects. There can be one or more project managers in your organization.
Program Manager: Oversees and leads a group of projects that are similar in nature. Project managers will usually report back to program managers.
Portfolio Manager: The highest level of PMOs and EPMOs. Oversees the strategic alignment and direction of projects and programs. Program managers will usually report back to the portfolio manager.

What Skills Are Important In Project Management?

Project management professionals must possess a combination of technical and non-technical skills in order for the project to be a success. They must be able to adapt and find creative solutions to overcome challenges. Here are the seven key characteristics of successful project management professionals:

Leadership: A good leader will be able to unify all of the team members and lead them to their aim.
Communication: Communicating well with your team members is essential for the coordination of all the tasks.
Motivation: Being motivated means that you will not only find ways to keep pushing on but will also be passionate about the project.
Organization: In order for everything to go smoothly, a project must be well organized with everyone doing their job.
Problem-Solving: Solving problems and overcoming unexpected challenges is crucial for your project to be a success.
Adaptability: Adapting to a new environment will help you stay up-to-date with the latest conditions and keep evolving.
Prioritization: It is very important to prioritize your tasks and do the most urgent ones at the beginning.

Final Thoughts

To sum up, project management may seem like something unimportant but it actually plays a major role in the processes within any business. Follow the tips in this article to make your project management better and more effective.

Can You Really Play Agile SAFe?

Written by Paul Oppong on September 5, 2019. Posted in Articles.

Agile SAFe has been touted by some as being a good solution for the implementation of agile in larger organisations.

However, ever since the idea was first initiated it has been a cause of controversy and disagreement in the agile community. It is helpful to assess whether organisations can really play agile SAFe, considering its benefits and challenges. It is also useful to think about practical factors associated with its implementation, to try and make any use of agile SAFe as beneficial as possible for organisations. These points are considered below.

What is Agile SAFe?

Before progressing, it is important to understand what is meant by agile SAFe. SAFe is an approach that was put forward in 2011, with a view to aiding software development teams to get improved products to market at a greater speed. SAFe stands for Scaled Agile Framework, and since its conception, organisations have been working to build tools that can help with its implementation within larger organisations. SAFe is a framework that aims to help in situations where scale is a factor. Working within SAFe, there is thought to be improved collaboration, especially across different teams, and the making of decisions is centralised. SAFe generally works with a Scrum central to the process, but there is a larger sprint which operates across several teams. Each of these teams use smaller sprints.

Benefits of SAFe

Advocates of the SAFe approach argue that this framework allows its users to use agile at scale. It is suggested that SAFe offers an increased level of agility and a more thorough agile implementation. Proponents of the approach argue that while SAFe may not be as effective as putting a pure agile system in place, in fact it does at least offer a starting point for bigger organisations to put in place more of an agile system. It is therefore suggested that SAFe is not really an absolute target, but rather that it may be used to get organisations moving in a direction towards real agility. It provides an opportunity for large organisations to gain some of the benefits of agile, when they otherwise might not be able to. This may be considered benefit enough by some organisations.

Challenges with SAFe

While SAFe appeared at first to offer an excellent solution as a scaled approach, in fact, evidence suggests that it has not delivered the hoped-for benefits. One of the problems with it has been unrealistic expectations within organisations. It is tempting to believe that SAFe can deliver magical results with little energy expended to achieve this. This is not the case. SAFe requires a transformation of mindsets, not just a few days of training. In fact, in 2017 the Association for Project Management found that mindset change is more important than changing methods. As such, SAFe requires fundamental change to organisational activities and behaviour to make it a success. This takes years rather than months to bring about, so it requires significant commitment and effort. It is not a wonder drug that can suddenly deliver tremendous results. In my experience, business leaders do not necessarily appreciate this. Those who believe SAFe is not helpful also argue that no organisation has ever said that it has been hugely beneficial for them. This is problematic.

Thoughts on Adopting Agile SAFe

Many agile experts argue that SAFe should not be adopted as it is not bona fide agile. Further, SAFe has been dubbed “unSAFe” by some of these same individuals. It is felt that SAFe works against one of the fundamental principles of an agile approach, that of focusing on people and their interactions rather than tools and processes. While on paper it might seem that this framework will offer flexibility, it goes against this when it is aimed to implement it from a practical perspective.

On the other hand, it cannot be ignored that agile SAFe may offer some benefits for organisations that want to start along the journey to true agility, and that this framework does offer an important opportunity for larger organisations that might otherwise not be able to make agile work. While SAFe may be a very imperfect solution, it does help with starting to address some of the challenges of project management within larger organisations.

At best however, it is worth noting that agile SAFe is likely to only work in some organisations, and even then, only some of the time. Each organisation will need to consider its own circumstances and the extent to which it can work on transformation towards an agile mindset as an end goal, for this to be of benefit.

For those that do want to play agile SAFe, it is highly recommended to put in place monitoring and measurement of certain goals. After all, any change ought to deliver benefits including some sort of return on investment. It is worth considering metrics that measure customer satisfaction, productivity, quality (fewer defects), cycle time and release time, stabilisation and employee satisfaction to identify if any of these have improved as a result of putting in place agile SAFe. If not, then the program is not worthwhile.

Summary

Agile SAFe has created a lot of controversy in the agile community. While SAFe does have the potential to bring about some change in working towards a scaled agile approach in larger organisations, there are serious concerns that it may be seen as a “wonder drug” and that many organisations do not put the time or effort required into delivering the transformation of mindsets needed to be truly agile. This can lead to SAFe being considered “unSAFe”. Those large organisations that do want to implement SAFe should perhaps view it as an important starting point along the road to eventually becoming truly agile, realising that the journey will take years rather than months. Having in place a system of measurements to ensure that return on investment is achieved through the use of such a program is highly recommended for those organisations that want to play agile SAFe.

Five Questions for BA John Fraser

Written by David Newstead on August 13, 2019. Posted in Articles.

John Fraser brings an energy and commitment to all his projects that truly compliments and builds upon his years of experience in strategic business process improvement.

In short, you know when John is in the room and today he joins me for five questions about his career and his insights on being a Business Analyst.

You bring a lot of enthusiasm to your work, what motivates you as a BA?

I am a BA Enthusiast that is committed to getting the job done. I do this by managing both expectations and project constraints, which results in an atmosphere where project members feel proud of the result and ensure client expectations are exceeded. Our Process & BA Capability Lead, Scott Rainey, always says “Our Business Analysis Team is directly connected to the problem statement and the value from business case to implementation,” and it’s the truth! What also motivates me is seeing BAs come into their own going from an Entry-Level to a Junior Role, to a Senior Role – to Thought Leaders in their craft!

What positive trends are you seeing across your BA community of practice? And how are you addressing the challenges that inevitably arise in BA work?

What is trending majorly is the skills for BAs to understand, Data Management, Data Visualization, and Robotic Process Automation to help streamline activities for organizations. To help combat BA Challenges, we meet bi-weekly and discuss challenges and come up with solutions to help address those challenges. In our Community of Practice, all the BAs have a voice. Our CoP’s purpose is to provide a forum for continuous improvement of North Highland’s Business Analysis skillset through collaboration, mentoring, and education.

Throughout your career, you’ve worked across several different industries. How has your BA role varied from one to another?

BA roles differ in organizations because some organizations want BAs to focus on one thing (i.e. Process Mapping) when that’s only a subset of a skilled Business Analyst. BAs should be involved in multiple areas to truly provide value back to any organization.

What’s your favorite technique?

My favorite technique is the Scope Context Model helps describes the intended business change by helping stakeholders understand:

How the solution contributes to the goals of the organization
The expected, provable measures that indicate solution success
When the solution is considered done
Who will be consulted for requirements information
Systems which might be impacted (or needed) by the proposed change
Users of the intended solution and how they will interact with it
Key assumptions, constraints and out of scope considerations

What project do you want to tackle next?

I would like to tackle a “game changing” effort that really pushes the needle for an organization that will benefit the industry and the BA’s role in its success.

Your Agile Might be Fake

Written by Paul Oppong on July 3, 2019. Posted in Articles.

“Agile” is a term commonly used in organisations of all shapes and sizes these days.

When I go into organisations, I hear leaders saying, “We use agile”, yet digging deeper, I find things aren’t quite, well, agile, in fact sometimes not at all. A fake idea of agile implementation is commonplace, and managers say the agile words without really understanding the principles and concepts behind them. This means that the team is not truly agile at all, and not reaping the rewards of being agile either. But what does fake agile look like, and how can this be diagnosed in an organisation?

Symptoms and Signs of “Fake Agile”

There are numerous signs and symptoms that an organisation is not being genuinely agile. One of the most common is perhaps the idea that a team can take the elements of agile that they like and use only these, discarding the rest. People who have implemented this approach will make comments saying that they use agile techniques while then going on to say, “Well, it’s not quite agile, we used what we liked from a few different models.”

Another common challenge is not really understanding the core concepts of agile, while still believing the team is working within them. For example, agile is fast, meetings should be fairly quick, while covering the activities of yesterday and today, and discussing barriers. The idea of a daily Stand-up meeting for instance in a Scrum or Kanban agile implementation is to keep it concise and to the point. Some teams find they are having stand-ups that last multiple hours. This indicates the agile implementation might be what it is meant to be and not really working. It might mean that the meeting probably has too many attendees, and in which case it might be possible to work in smaller groups instead. Alternatively it can mean the team is working in a hierarchical manner, which is not the point of agile.

When a team is truly agile it will continuously deliver value to customers. This is a critical underpinning principle of agile. The reason for introducing this concept to agile, was that in the past, developers would work on a project for months, deliver it to the end customer, and by the time it was delivered, requirements would have moved on, or it would not do quite what the customer needed. This means that there is a need to understand customer needs throughout the development process. This is an idea that agile is built around, and hence the principle of continuously delivering value. This leads to the ability to pinpoint other clear indicators of fake agile. It follows that if teams are not securing feedback from customers regularly, and looking at it quickly, then they are not continuously delivering value to them. Feedback is a regular and integral part of agile. What is more, if no time or money is budgeted for change to the project then the team is probably not agile. This is because continuously providing value will invariably require looking at ways to change the development, so it more closely aligns with customer needs, once feedback is received.

Three Key Questions to Diagnose “Fake Agile”

There are some questions that can be posed to those leading so-called agile programs to determine if they really are embracing agile concepts. You might ask, “Do real users see iterative working version of the product, and if so, how often?” If the answer is no, agile is not in place. It is also a problem if customers only see iterations every few months. This is not agile project management either. The end users should be seeing and feeding back on iterations with regularity.

Another question that you could ask is, “How frequently is feedback from users converted into work activities for teams?” If the answer is never, the team is clearly not agile. If the leader responds that this happens within time frames of less than one month, then it is possible that agile is operating as it should. After all, as we have seen above, agile operating is all about meeting customer requirements by taking on board feedback and incorporating it into the project.

A third key question to ask is about team empowerment. You may ask, “What level of empowerment do team members have? Can they change processes and requirements based on user feedback and on what they learn?” Empowerment of team members is a core principle of agile operating. Leaders that say any answer that includes, “Yes they are empowered but…” are probably not following agile methodology. Any indication of hierarchical, top-down decision making goes against the agile way of working.

Summary

Many business leaders think they are being agile. They also like to say it, because agile is a popular buzz word. That does not mean they actually are agile. Any so-called “agile” approach that just takes the parts of agile the leader likes and ignores the rest is not truly agile. Underlying agile is fast, iterative development, with feedback taken on board along the way, to continuously deliver value to customers. Where an “agile” solution does not do this – beware! It is almost certainly going to be fake agile.

Yet another enquiry to make is whether the whole project operation is agile. This will help pick out those leaders that think they have got the best of both worlds by using some agile principles combined with other more traditional forms of project management because these are more palatable with their idea of control and command. If the answer is no, then the team is not working in an agile manner. In fact, if the answer is “Partly”, this is also still true. When agile teams work in an agile way to start with, and then use bureaucracy later on in the process, this is not agile operating. The only correct answer to this type of question is, “Yes” without any caveats being applied.

Business Analyst = Cybersecurity Expert

Written by Brad Egeland on June 27, 2019. Posted in Articles.

Ok, this may be a stretch to say “cybersecurity expert”, but I got your attention, didn’t I?

To me – and on all the “real world” tech projects I’ve managed – the business analyst has played the role of part-time tech and full-time tech liaison with the technical team on the project. They run the requirements definition portion of the project, they document – with project manager assistance – the functional requirements for the project and help extract the project client’s current business processes that are or will be affected by the project as well as helping to analyze and define what the new processes need to look like as we build the solution that will satisfy the business needs of the project client.

Easy process? No. Lots of work involved? Yes. Lots of documentation involved as well and much of it will become the basis for the full, detailed requirements document as well as what the ultimate solution is tested against as we run through user acceptance testing (UAT) with the project client. Defining all of this is critical to selecting the right technology, fully and correctly defining what the real requirements are, fully understanding what the “as-is” and “to-be” business and technical processes are or planned to be and fully preparing for the rest of the project.

Now, that said, the project manager has his role. The tech lead and team have their roles. Often, everything else might fall to the business analyst. And as we manage projects in ever increasing dangerous waters filled with hackers and data breaches, the business analyst may be taking on a new role in the smaller and/or less prepared project execution organizations. That is the role of the cybersecurity “expert.”

I’ve often said two things: data security and hacking are such a growing concern that no project should be consider “safe.” Hackers are always one step ahead of us and if you were on their radar you would have already been affected. But you may get lucky for a while. Sooner or later you will be affected to some small or potentially large degree. You can’t necessarily completely avoid or mitigate the hacker / data breach risk. But you can take measures. Does every project need some involvement from security as a part of the project team – if only as a sit-in during risk identification? I think so. Will all organizations eventually have a team of cybersecurity experts? Probably. But for now, that cybersecurity team or presence may just be one untrained or “in training” individual who has a strong interest in cybersecurity (or is forced to have that interest). And who is that likely candidate? The business analyst. In fact, the smart organization would be bringing in cybersecurity trainers right now to start getting the ground work laid for a solid team of security individuals tasked with keeping organization and customer data and systems safe from harm. The larger organizations should be putting a CSO (chief security officer) in place to guide the security infrastructure down the right path and career growths for those hired to be part of that infrastructure.

So, does the business analyst really = cybersecurity expert? In some cases, yes. And in the case where there is no real security awareness, representation or position on the project and in the organization the answer – in my opinion – is a definite yes. Get those BA’s in the organization as a whole at least educated on cybersecurity at a high level so they can begin to integrate cybersecurity awareness on the projects, the project teams and with the company’s senior management. It will give your project clients a better comfort level of satisfaction and confidence and hopefully provide some useful mitigation planning. There are some cybersecurity 101-type documents, videos, webinars and classes out there – often for free. Yes, that is all better than nothing. It’s what I’m immersing myself in – you learn something new and helpful with every watch or read. And I’ve attended many Las Vegas versions of the Black Hat digital security conferences over the years. They aren’t cheap, but they are if you get in for free with a media pass as I do because I’m also an author of these articles, white papers, eBooks and videos.

To get to the point of the proper cybersecurity presence, you can do one or more of the following 4′ things…

If you are a project-centric professional services organization – start with your business analyst or tech leads. In my opinion, this is probably the best way to start spreading the cybersecurity expertise to those who are most entrenched daily in the projects underway, about to happen, being planned and the customers they are working with. And it ensures that every project has a cybersecurity / cyber risk planning and management presence. That is priceless. And you have homegrown talent – also priceless.

Hire an outside consultant to review processes, projects and infrastructure and make recommendations. Expensive, but it can be a good start to building your own cybersecurity infrastructure. The expert will tell you what your needs likely are and help you plan a path to getting there including any re-organization and hiring you need to do today, a month from now and a year from now to be successful and safe. Expensive, but it will help the organization determine their real needs and how to get to the point of fulfilling those needs properly.

Hire cybersecurity talent and build a staff. If you are large organization handling sensitive internal or customer data, then you probably should have done this yesterday. So do it tomorrow and don’t procrastinate. And put a C-level security person in the organization – a CSO.

Hire an outside consulting organization to take part in necessary projects. Not your best choice for the money, but this can be a stop-gap measure if you find yourself suddenly immersed in projects that are highly data sensitive. As you move in that direction, the last thing you want is project failure and a big, highly visible data breach. So, if you must, then do this. It is far better than the alternative. And should something bad happen, it is far less expensive than the hack exposure.

Summary

Now is the time for action. Not tomorrow, not next year. Procrastination can cost millions in this instance. Train, buy, hire, or whatever… do something to protect your projects, customers and data.